---
sidebar_position: 7
---

# Glossary

## Semaphore identity

The identity of a user in the Semaphore protocol.
An identity contains the following three values:

-   [Identity commitment](#identity-commitment): the public value.
-   Identity trapdoor and identity nullifier: secret values known only by the user.

## Identity commitment

The public [Semaphore identity](#semaphore-identity) value used in [Semaphore groups](#semaphore-group).

Semaphore uses the [Poseidon](https://www.poseidon-hash.info/) hash function to create the identity commitment from the Semaphore identity secret values.

## Semaphore group

A group is a binary incremental [Merkle tree](#merkle-tree) in which each leaf contains an [identity commitment](#identity-commitment) for a user.
The identity commitment proves that the user is a group member without revealing the Semaphore identity of the user.

Semaphore uses the **Poseidon** hash function to create Merkle trees.
For more information, see the [Poseidon website](https://www.poseidon-hash.info/).

## Merkle tree

A tree in which every leaf (i.e., a node that doesn't have children) is labelled with the cryptographic hash of a data block,
and every node that isn't a leaf is labelled with the cryptographic hash of its child node labels.
In zero-knowledge protocols, Merkle trees can be used to efficiently summarize and validate large data sets.
To validate that a tree contains a specific leaf, a verifier only needs a portion of the complete data structure.

For more information, see [Merkle tree in Wikipedia](https://en.wikipedia.org/wiki/Merkle_tree).

## Nullifier

A value used to prevent double entry or double signaling.

See [Circuit nullifier hash](/V3/technical-reference/circuits/#nullifier-hash).

## Relay

A third-party who receives a fee for including relayed transactions in the blockchain (McMenamin, Daza, and Fitz. https://eprint.iacr.org/2022/155.pdf, p.3).
To preserve the anonymity of the user broadcasting a signal with Semaphore, an application may use a relayer to post the signal transaction to Ethereum on behalf of the user.

Applications may provide rewards for relayers and implement front-running prevention mechanisms, such as requiring the signals to include the relayer’s address, binding the
signal to that specific address (https://semaphore.pse.dev/whitepaper-v1.pdf, p.6).

## Trusted setup files

The secure, verifiable parameters generated by Semaphore's trusted setup ceremony.
Semaphore uses the trusted setup files to generate and verify valid zero-knowledge proofs.
To generate or verify valid zero-knowledge proofs with Semaphore, applications must include the following Semaphore _trusted setup_ files:

-   semaphore.zkey
-   semaphore.wasm
-   semaphore.json

For a complete list of ready-to-use files, see [trusted-setup-pse.org](https://www.trusted-setup-pse.org).
To learn more, see the [trusted setup ceremony](https://storage.googleapis.com/trustedsetup-a86f4.appspot.com/semaphore/semaphore_top_index.html).

## Signals

The term "signals" in Semaphore refers to the values the user broadcasts when voting, confirming, sending a message and so on. On the other hand, "[signals](https://docs.circom.io/circom-language/signals/)" in Circom refers to data that contain elements within the field of Z/pZ. In Circom, "signals" can be defined as input or output, and are considered intermediate signals otherwise.
