Simple Summary

A standard interface for a “Verifier Registry”’” contract, through which all zk-SNARK verification activity can be registered.


The following standard allows for the implementation of a standard contract API for the registration of zk-SNARKs (“Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge”), also known as “proofs”, “arguments”, or “commitments”.

TODO: Which functionality is exposed in this standard interface?


zk-SNARKs are a promising area of interest for the Ethereum community. Key applications of zk-SNARKs include:

  • Private transactions
  • Private computations
  • Ethereum scaling through proofs of ‘bundled’ transactions

A standard interface for registering all zk-SNARKs will allow applications to more easily implement private transactions, private contracts, and scaling solutions; and to extract and interpret the limited information which gets emitted during zk-SNARK verifications.

:warning: TODO: Explain the motivation for standardizing a registry, other than simply standardizing the verifier interactions.

⚠️ TODO: Explain the benefits to and perspective of a consumer of information. I.e. the thing that interfaces with the standard verifier registry.


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

pragma solidity ^0.5.6;

/// @title EIP-XXXX zk-SNARK Verifier Registry Standard
/// @dev See
///  Note: the ERC-165 identifier for this interface is 0xXXXXXXXXX.
/// ⚠️ TODO: Set the interface identifier
interface EIP-XXXX /* is ERC165 */ {

  event NewProofSubmitted(bytes32 indexed _proofId, uint256[] _proof, uint64[] _inputs);

  event NewVkRegistered(bytes32 indexed _vkId);

  event NewVerifierContractRegistered(address indexed _contractAddress);

  event NewAttestation(bytes32 indexed _proofId, address indexed _verifier, bool indexed _result);

  function getVk(bytes32 _vkId) external returns (uint256[] memory);

  function registerVerifierContract(address _verifierContract) external returns (bool);

  function registerVk(uint256[] calldata _vk, address[] calldata _verifierContracts) external returns (bytes32);

  function submitProof(uint256[] calldata _proof, uint64[] calldata _inputs, bytes32 _vkId) external returns (bytes32);

  function submitProof(uint256[] calldata _proof, uint64[] calldata _inputs, bytes32 _vkId, address _verifierContract) external returns (bytes32);

  function submitProofAndVerify(uint256[] calldata _proof, uint64[] calldata _inputs, bytes32 _vkId, address _verifierContract) external returns (bytes32);

  function attestProof(bytes32 _proofId, bytes32 _vkId, bool _result) external;

  function attestProofs(bytes32[] calldata _proofIds, bytes32[] calldata _vkIds, bool[] calldata _results) external;

  function challengeAttestation(bytes32 _proofId, uint256[] calldata _proof, uint64[] calldata  _inputs, address _verifierContract) external;

  function createNewVkId(uint256[] calldata _vk) external pure returns (bytes32);

  function createNewProofId(uint256[] calldata _proof, uint64[] calldata _inputs) external pure returns (bytes32);



interface ERC165 {
    /// @notice Query if a contract implements an interface
    /// @param interfaceID The interface identifier, as specified in ERC-165
    /// @dev Interface identification is specified in ERC-165. This function
    ///  uses less than 30,000 gas.
    /// @return `true` if the contract implements `interfaceID` and
    ///  `interfaceID` is not 0xffffffff, `false` otherwise
    function supportsInterface(bytes4 interfaceID) external view returns (bool);


⚠️ TODO: Add Rationale section.

Backwards Compatibility

⚠️ TODO: Add Backwards Compatibility section.

Test Cases

Truffle tests of example implementations are included in this Repo.

⚠️ TODO: Reference specific test cases because there are many currently in the repository.


Detailed example implementations and Truffle tests of these example implementations are included in this Repo.

⚠️ TODO: Update referenced verifier registry implementations so that they are ready-to-deploy or reference deployed versions of those implementations. At current, the referenced code specifically states “DO NOT USE THIS IN PRODUCTION”.

⚠️ TODO: Provide reference to an implementation which interrogates a standard verifier registry contract that implements this standard.


⚠️ TODO: Update references and confirm that each reference is cited (parenthetical documentation not necessary) in the text.


  1. ERC-20 Token Standard. ./

  2. ERC-165 Standard Interface Detection. ./
  3. ERC-173 Contract Ownership Standard (DRAFT). ./
  4. ERC-196 Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. ./
  5. ERC-197 Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. ./
  6. Ethereum Name Service (ENS).
  7. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels.
Educational material: zk-SNARKs
  1. Zcash. What are zk-SNARKs?
  2. Vitalik Buterin. zk-SNARKs: Under the Hood.
  3. Christian Reitweissner. zk-SNARKs in a Nutshell.
  4. Ben-Sasson, Chiesa, Tromer, et. al. Succinct Non-Interactive Zero Knowledge for a von Neumann Architecture.
Notable applications of zk-SNARKs
  1. EY. Implementation of a business agreement through Token Commitment transactions on the Ethereum mainnet.
  2. Zcash.
  3. Zcash. How Transactions Between Shielded Addresses Work.
Notable projects relating to zk-SNARKs
  1. libsnark: A C++ Library for zk-SNARKs (“project README)”.
  2. ZoKrates: Scalable Privacy-Preserving Off-Chain Computations.
  3. ZoKrates Project Repository.
  4. Joseph Stockermans. zkSNARKs: Driver’s Ed.
  5. Christian Reitweissner - snarktest.solidity.
Notable ‘alternatives’ to zk-SNARKs - areas of ongoing zero-knowledge proof research
  1. Vitalik Buterin. STARKs.
  2. Bu ̈nz, Bootle, Boneh, et. al. Bulletproofs.
  3. Range Proofs.
  4. Apple. Secure Enclaves.
  5. Intel Software Guard Extensions.

Copyright and related rights waived via CC0.