ERC-8036: ZK Presentation Interface for MTC (8035)

y_hoshino · October 2, 2025, 4:28pm

MTC-ZK defines an optional, fixed Groth16-style ABI (proveMetric) to verify predicates only (e.g., score ≥ threshold) against MTC Core (ERC-8035) anchors—without revealing raw values.

Problem & motivation
dApps often need threshold checks while preserving privacy and supporting revocation at scale. MTC-ZK provides a stable verifier ABI and binding rules so wallets/dApps can verify the same predicate the same way.

Scope

proveMetric(a,b,c,publicSignals) with fixed order [mode, root, nullifier, addr, threshold, leaf]
Binding (MUST): root == leafFull (current Core anchor), tokenId == tokenIdOf(address(uint160(addr)))
Policy (MUST): mode allowed by Core mask; mask mismatch and mode == 0 revert
Domain separation (circuit): treeLeaf = Poseidon(leaf, addr, keccak256(abi.encode(chainid(), address(this))))
ERC-165 compliance (MUST)
Optional events: VerifierSet, ProofVerified

Comparison semantics
GT: value > threshold; LT: value < threshold; EQ: value == threshold (inclusive).

Draft EIP (EIP-1 compliant)

github.com/ethereum/ERCs

Add ERC: ZK Presentation Interface for MTC

master ← YutaHoshino:feat/mtc-zk

opened 05:20PM - 02 Oct 25 UTC

YutaHoshino

+140 -0

The following PR has been split. https://github.com/ethereum/ERCs/pull/1229 …Summary MTC-ZK defines an optional, fixed Groth16-style ABI (`proveMetric`) to verify **predicates only** (e.g., score ≥ threshold) against MTC Core anchors—without revealing raw values. Files: EIPS/eip-8036.md Discussion: https://ethereum-magicians.org/t/erc-8036-zero-knowledge-presentation-interface-for-multitrust-credential-8035/25648

Reference implementation (non-normative)

github.com/hazbase/contracts

verifier/circom-zk/circuit.circom

main

pragma circom 2.1.8;

include "poseidon.circom";
include "mux1.circom";
include "bitify.circom";

template GEQ32() {
    signal input  a;           // 0 … 2^32-1
    signal input  b;
    signal output out;         // 1 ⇔ a ≥ b

    signal diff;
    diff <== a + (1 << 33) - b;        // 0 … 2^33 + 2^32 − 2

    component bits = Num2Bits(34);
    bits.in <== diff;

    out <== bits.out[33];
}

This file has been truncated. show original

github.com/hazbase/contracts

verifier/circom-zk-group/circuit.circom

main

pragma circom 2.1.8;

include "poseidon.circom";
include "mux1.circom";
include "bitify.circom";

/**************************************************
 * MerkleProof — fixed-depth Merkle inclusion check
 *  - `indices` are boolean (0: left, 1: right)
 **************************************************/
template MerkleProof(n) {
    signal input root;
    signal input leaf;
    signal input siblings[n];
    signal input indices[n];

    component hashers[n];
    signal cur[n + 1];
    cur[0] <== leaf;

This file has been truncated. show original

Related
Core discussion: ERC-8035: MultiTrust Credential (MTC) — Core

Feedback
As this is our initial draft, we’d greatly appreciate broad feedback—on terminology, spec clarity, and interop. Suggestions and alternatives are welcome.

y_hoshino · December 17, 2025, 6:43am

Based on the discussion, the draft now formally includes an additive ZK presentation extension while keeping the original fixed Groth16 interface intact.

ChangeLog

Key updates:

Introduced an additive interface (IMultiTrustCredentialZKEx) for richer predicates.
Formally defined RANGE and DELTA (epoch-based) predicate semantics as OPTIONAL extensions.
Clarified that the original fixed ABI remains the stable baseline (v1), preserving backward compatibility.
Unified binding rules (anchor binding, address binding, comparison mask enforcement, and domain separation) across both the base and extended interfaces.
Clarified mode semantics as a bitmask (GT/LT/EQ), with mode == 0 allowed only for KYC-only proofs.

Many thanks to allfinan for the thoughtful feedback and suggestions around range predicates, delta constraints, and epoch-based freshness.
The intent remains to keep MTC Core minimal, while allowing credit- and risk-oriented logic to evolve cleanly at the presentation layer.

Feedback on the extended predicate model and interface shape is very welcome.