Workshop Submissions

The ZKProof Standardization effort is now accepting submissions to the 4th ZKProof Workshop, which will be held online 19-29 April 2021. The workshop addresses the security, implementation and applications of zero-knowledge proofs. The main goal of this workshop is to convey and facilitate progress in zero-knowledge proof technology, by sharing knowledge among participants and by creating public living documents that convey the state of the art.

Proposals accepted to the workshop are meant to serve as references and guidelines agreed upon by the community, that promote correct usage and interoperability of zero-knowledge proofs. We envision that subsequent work, to be defined in collaboration with standard bodies, will be required to gain official status as a normative standard.

Proposals may be any of the following:

  • Cover a new topic within the scope of ZKProof (see below)
  • Continue and advance the deliberations on existing topics (i.e. those covered by prior accepted proposals and working groups). In this case, submissions should describe the progress made or novelty since the 3rd Annual ZKProof Workshop.
  • Systemization of knowledge and useful frameworks for describing the state of the art. (These may be eventually integrated into the Community Reference document).

(Unlike the 3rd ZKProof Workshop, there is no explicit separation of tracks).

The accepted submissions may be invited for publication in a dedicated proceeding; we expect the authors to make revisions to their initial submissions based on feedback and discussion at the workshop, as discussed below.

Submission of similar material to other venues (whether concurrent or otherwise) is permitted.

Important Dates

  • 23 February 2021, 11:59pm PST: Submission deadline
  • 25 March 2021: Notification of acceptance/rejection to the workshop
  • 19-29 April 2021 (Online): In-workshop presentation and discussion
  • 1 June 2021: Revised version due for proceedings
Submit Paper

Submissions on any topic related to zero-knowledge proofs are welcome. Please review the current ZKProof documents for examples. This includes, but is not limited to, the following:

  • Terminology, definitions and models
  • ZK proof-system constructions and their building blocks
  • Implementation of ZK proof system
  • Interoperability and integration between proof-system implementation, or components thereof (e.g. APIs and file formats)
  • Benchmarking
  • Applications of ZK proof systems (in particular, reusable/abstracted application-level protocols)
  • Domain-specific languages for expressing statements to be proven in zero knowledge
  • Security analysis and formal verification

The process is oriented towards curating pertinent work along the above tracks; sharing it among the workshop participants to disseminate the knowledge and collect feedback, and then guiding it towards subsequent inclusion in the body of documents maintained by the ZKProof Standardization effort.


Submissions can be made at until the submission deadline.

Each submission will be reviewed by the Review Committee, which will decide whether to accept it to the conference. Author names will be visible to reviewers; reviewer names will not be visible to authors.


Accepted submissions will be presented at the workshop by one of the authors, and discussed by workshop participants in dedicated working groups. Notes will be taken.

Submissions must be prepared in LaTeX, 11-point font, single-column. There is no page limit.

The structure is up to the authors’ discretion, but should include all of the following:

  • Title, prefixed with either “Proposal:” or “SoK:” to designate the track
  • Author names and affiliations
  • Background and motivation: contextualize the problem being addressed, and motivate its importance and the potential impact of the submission. Provide references
  • Scope: it should be clear what is included the scope of submission and what is excluded.
  • Terminology: use terminology consistent with the existing ZKProof Standardization documents, and in particular the Community Reference document, whenever possible. When new terminology is required, introduce it explicitly.
  • Security: explicitly discuss security implications of the submission (if any).
  • Implementation: if relevant, submit an open source prototype/prototype implementation, by including a reference to the code repository with the code.

Expectations on disclosure and licensing of intellectual property

See the ZKProof Intellectual Property Policy.


  • Abhi Shelat (Northeastern University)
  • Eran Tromer (Columbia University and Tel Aviv University)


  • TBD
Submit Paper

For More Information

See the ZKProof Standardization Effort website, or contact the Review Committee chairs.