This standard formalizes ZKMeta, a minimal interface for contracts that verify or depend on zero-knowledge proofs. It defines how to expose a proof-system identifier, circuit identifier, circuit version, public-input schema (hash and URI), and verification-key URI. The goal is to enable interoperable wallet, relayer, explorer, rollup, and dApp tooling without prescribing any specific proof format.
Zero-knowledge applications currently lack a standard way to publish the "shape" of their proofs. Projects using Groth16, Plonk, Halo2, or zkVMs each deploy custom artifacts, leaving integrators unable to reliably determine how to interact with a system without bespoke adapters.
Unlike previous attempts that aimed to standardize verification logic (e.g., ERC-1923), ZKMeta focuses solely on metadata discovery. By standardizing how to locate the verification key, public input schema, and circuit identity, this standard creates a "ZK ABI" that unlocks capabilities previously impossible in a fragmented ecosystem:
circuitVersion changes to alert users if a protocol silently downgrades to an older, vulnerable circuit or changes constraints without announcement.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
| Identifier | Proof System | Notes |
|---|---|---|
0x0001 | Groth16 | BN254 (e.g., snarkjs) |
0x0002 | Plonk | BN254 variant |
0x0003 | Halo2 | Plonkish family |
0x0004 | zkSTARK | General STARK provers |
0x0005 | zkVM | e.g., RISC-V/Jolt/RISC Zero |
Additional identifiers MUST be proposed in the discussion thread and MUST NOT collide. Unknown identifiers SHOULD be treated as unsupported by tooling.
circuitId() MUST be a content hash (e.g., keccak256 or multihash) of the canonical circuit artifact used to derive the verification key.circuitVersion() MUST increase upon any breaking change to constraints or public-input semantics. Projects SHOULD use the high 32 bits for major and low 32 bits for minor.publicInputsSchemaHash() MUST match the document at publicInputsSchemaURI().publicInputsSchemaURI() and verificationKeyURI() SHOULD be content-addressed (ipfs://, ar://, bzz://). If HTTPS is used, the URI MUST include a URL fragment containing the Keccak-256 hash of the resource content in hexadecimal format (e.g., https://example.com/schema.json#0x...) to ensure integrity.CircuitMetadataUpdated SHOULD be emitted in the same transaction that makes new metadata observable.publicInputsSchemaHash() matches the hash of the fetched schema document.verificationKeyURI()’s hash fragment.CircuitMetadataUpdated MUST be emitted in the same transaction that makes new metadata observable to prevent indexer race conditions.Content addressing
Prefer IPFS/Arweave/Swarm CIDs or HTTPS with #hash to ensure immutability and reproducibility.
Versioning discipline
Treat schema or circuit constraint changes as major; cosmetic or doc updates as minor.
Indexing
Indexers and explorers SHOULD subscribe to CircuitMetadataUpdated instead of polling getters.
bytes4 proof-system code minimizes calldata while remaining extensible.Existing contracts may expose an adapter that implements IZKMetadata. Legacy systems can deploy a read-only facade or off-chain router for downstream tooling. No existing ERCs are modified.
If tooling does not verify publicInputsSchemaHash() against the downloaded document, a malicious frontend or gateway could serve a modified schema. This would allow an attacker to mislabel public inputs (e.g., swapping "Token Amount" for "Nonce"), deceiving users about what the proof actually attests to.
Relying on HTTP URIs without hash fragments allows a server administrator to silently swap the verification key. This could enable the server admin to create fake proofs for a new (compromised) circuit while the contract still points to the old URI.
If the CircuitMetadataUpdated event is not emitted atomically with the state change, off-chain indexers might read stale metadata values (e.g., an old verification key) while processing the update event, leading to widespread denial of service for proof generation.
Copyright and related rights waived via CC0.