The structure of the QuantumProtocolZoo is defined by a hierarchy of categories shown in the figure below. Find pages grouped by category in the Library section in the menu bar. Pages belonging to the same category all have the same fields. The categories and the fields that describe them are explained below.

Categories
Functionality pages
A functionality page provides information about a specific functionality, which is what links the protocol to a real-world application. In other words, it describes what a protocol is supposed to achieve, the scenarios where this task is needed, its key properties (like security), and which protocols in the Zoo implement it.
A functionality page provides information about a specific functionality, which is what links the protocol to a real-world application. In other words, it describes what a protocol is supposed to achieve, the scenarios where this task is needed, its key properties (such as security), and which protocols in the Zoo implement it.
Protocol pages
A protocol page is where you can get information about a specific protocol. Every protocol in the Zoo is linked to the functionality it implements. Each protocol page is designed to be accessible to people with different levels of knowledge and expertise. You’ll start with a general description of the protocol, followed by a more detailed, step-by-step explanation in plain language. For those looking for even more precision, there’s a Protocol Description section, which presents the protocol in pseudo-code style with necessary mathematical notations. In most cases, you’ll also find additional useful information, such as the assumptions the protocol relies on, its key properties, implementation requirements, simulation codes, and even details about experimental realizations. Basically, everything you need to know about the protocol is there! Protocols can come in different levels of hierarchy, some more high-level (using other protocols inside them) and some more low-level, but they both have the same page layout.
Nodal Subroutine pages
Sometimes, a protocol requires one of the parties to run a local procedure, which can be complex and involve multiple steps. We call these Nodal Subroutines (well because they are executed by a single node in the network). Keep in mind that not every protocol has a nodal subroutine (sometimes the local steps are simple enough to include within the protocol itself).
Physical Resource pages
A quantum protocol ultimately runs on a physical network, where quantum parties use quantum mechanical devices and resources to run it. Every quantum protocol relies on some physical resource, whether it’s a device that prepares or measures quantum states, or a communication channel for sending quantum states or classical messages. Understanding the physical resources required for a protocol is an important step toward implementing it in the lab or even simulating it.
Fields in pages
Functionality Fields
- Functionality Description: A short description of the task that should be achieved.
- Protocols: The list of all the protocols that implement this functionality and achieve the task that it describes.
- Classical Analogues: Does this functionality have any classical counterpart?
- Real-world Use Cases: Here, you mention all the real-world applications that use this cryptographic functionality.
- Properties: This is where you describe the technical (often cryptographic) features of this functionality. As an example, most functionalities have notions of correctness and completeness (or security) that are specific to that functionality and can be defined here.
- Further Information: Any other information about this protocol that you would like to include.
Protocol fields
- Introduction: A brief description of the protocol and what it does.
- Related Paper(s): Here, you mention the title and link to related papers to this protocol. At least one paper, which is the one from which the specific protocol is adopted, needs to be added.
- Outline: A wordy description of the protocol, in other words, how the protocol works. In this field, you should avoid any formulas or very technical terms. The idea is for a non-technical reader to be able to read and understand this.
- Assumptions: State all the assumptions that this protocol relies on.
- Requirements: Provide information about technological readiness needed for this protocol, such as quantum network stage, and if available, parameter ranges and benchmark values.
- Notation: Every symbol and notation that is used later in the technical description of the protocol should be listed and defined here.
- Properties: Technical and cryptographic properties of the protocol.
- Technical Description: Here, the protocol is described in a technical way and ideally in a pseudocode style, such that it would be easy to follow step-by-step and suitable for a coder to implement.
- Experimental Implementations: Have there been any experimental implementations of this protocol? If yes, briefly mention them! Don’t forget links and references.
- Related Codes: Are there any code that implements/simulates this protocol? Add them here with a short description. Even if there are already some codes, you can always add a new one!
- Further Information: Anything else about the protocol that needs to be added goes here. This also includes very similar versions of the same protocols with minor differences, so that you don’t have to repeat the majority of the protocol and can only mention here what is different.
Nodal Subroutine and Physical Resource fields
The Nodal Subroutine page structure mimicks the protocol one. Please refer to the above list for field descriptions. Physical Resources are described a single paragraph so they do not have fields.

