Semaphore

The core cryptographic element of Semaphore is the Identity Commitment. Each user generates a secret identity (a private key) and publishes a one-way hash of it to a smart contract. This commitment acts as a pseudonymous identifier within a group, allowing users to prove membership without linking the commitment back to their off-chain identity.

A Nullifier is a unique hash generated for each action (or 'signal') a user makes. Its primary function is to prevent double-signaling—ensuring a single group member cannot vote twice or perform the same action more than once. The nullifier is derived from the user's secret and the specific context of the action, making it verifiably unique without revealing who produced it.

Semaphore uses zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) as its proving mechanism. A user generates a proof that demonstrates:

• They possess a valid secret identity for an existing Identity Commitment in the group's Merkle tree.
• They correctly computed the Nullifier for this specific action.
• They have not revealed their identity. The proof is verified on-chain, confirming the statement's truth without exposing any underlying private data.

Group membership is managed via an on-chain Merkle tree, where each leaf is a member's Identity Commitment. The tree's root serves as the public, concise representation of the entire group. Users can join by adding their commitment, and the smart contract updates the root. To generate a proof, a user must provide the Merkle path (siblings) proving their commitment is part of the current root, enabling efficient verification of membership.

These two components define the context and content of an action.

• External Nullifier: A public identifier for a specific polling event or context (e.g., "Proposal #5 Vote"). It ensures nullifiers are scoped, so a user can vote in multiple polls without conflict.
• Signal: The arbitrary data being broadcast anonymously, such as a vote (e.g., "1" for yes), an endorsement, or a message. The signal is hashed and included in the proof generation.

The Verifier Contract is a smart contract containing the zk-SNARK verification key. Its sole function is to verify the cryptographic proof submitted by a user. It checks that the proof is valid for the given public inputs: the current Merkle root, the nullifier, the external nullifier, and the signal hash. If verification passes, the contract can execute a trusted action (like recording a vote) based on this anonymous, valid signal.

Enables private, sybil-resistant governance where users can prove they are a member of a DAO or token-holder group and cast a vote without revealing their identity or how they voted. This protects voter privacy and prevents coercion.

• Key Mechanism: Uses a nullifier to prevent double-voting while keeping the voter's identity secret.
• Example: A DAO can conduct a sensitive treasury allocation vote where members' choices remain confidential.

Allows projects to distribute tokens or NFTs to a verified group (e.g., early users) while recipients can claim them anonymously. Users prove they are on the eligibility list without linking their claim transaction to their original identity.

• Prevents: Chain analysis that could deanonymize wealth or activity.
• Benefit: Separates proof of past action from current on-chain identity.

Websites or applications can grant access or features to users who prove membership in a group (e.g., "holders of a specific NFT") without requiring them to connect a wallet that would reveal their entire asset portfolio.

• Use Case: Gated content for a subscriber group where anonymity among members is desired.
• Technology: Relies on generating a zero-knowledge proof of group membership.

Provides a secure channel for members of an organization to submit verifiable feedback or reports. The system can prove the submitter is a legitimate employee or member, but the submission is untraceable to their individual identity.

• Guarantees: Authenticity of source (is a member) with anonymity of the actor.
• Application: Internal DAO reporting mechanisms or anonymous suggestion boxes.

Users can build a private reputation by accumulating Semaphore signals (e.g., positive reviews, completions) linked to their anonymous identity. They can later prove a reputation score or history of actions without exposing the details of each action.

• Core Concept: Decouples identity from verifiable credentials.
• Example: Proving you have completed 50 tasks on a platform without revealing which specific tasks.

Serves as a foundational primitive for privacy pools or mixer alternatives. Users can prove they have "clean" funds (e.g., not from a known hack) and deposit them into a pool, then withdraw to a new address with broken on-chain links, all while providing a compliance-friendly proof.

• Advantage over traditional mixers: Can include exclusion proofs to blacklist illicit funds.

Semaphore's security is built on zero-knowledge proofs (ZKPs), specifically zk-SNARKs, and Merkle tree accumulators. The protocol uses a decentralized identity commitment tree where users prove membership and generate a signal proof without revealing their identity. The soundness of the system depends on the computational hardness of the underlying cryptographic assumptions, such as the discrete logarithm problem.

A critical trust assumption is the secure generation of the zk-SNARK proving and verification keys via a trusted setup ceremony (e.g., the Perpetual Powers of Tau). If this ceremony is compromised, an adversary could generate false proofs. The protocol mitigates this by using a multi-party computation (MPC) ceremony with many participants, where only one honest participant is needed for security, making it 'trust-minimized' but not trustless.

User anonymity relies on the secrecy of the identity nullifier and identity trapdoor. If these are leaked, an identity can be de-anonymized. The protocol ensures:

• Unlinkability: Different signals from the same user cannot be linked.
• Double-signaling prevention: A user cannot vote twice in a poll, enforced by the public nullifier hash.
• Selective disclosure: Users can optionally reveal their identity with a nullifier for specific applications.

Applications built with Semaphore often depend on external data or services, introducing additional trust vectors. For example:

• Group Management: Trust in the entity that adds/removes members from the Merkle tree (could be a smart contract or a committee).
• Data Feeds: If a proof verifies off-chain data (e.g., "prove you are a citizen"), trust in the oracle or attestation service is required.
• Relayer Networks: To preserve privacy, users may rely on third-party relayers to pay gas fees, trusting them not to censor transactions.

The on-chain Verifier contract is a critical component. Its security depends on:

• Correct implementation: Bugs in the verification logic could accept invalid proofs.
• Upgradability: If the contract is upgradeable, trust in the upgrade mechanism (e.g., a multisig) is required.
• Blockchain consensus: The protocol inherits the security of the underlying blockchain (e.g., Ethereum) for finality and censorship resistance.

Beyond cryptography, real-world deployments face other risks:

• Sybil Attacks: While identities are anonymous, cheap identity creation can spam a system. This is mitigated by requiring proof of personhood or stake to join a group.
• Timing & Metadata Analysis: Network-level metadata or the timing of transactions could be used for correlation attacks.
• Front-running: In blockchain applications, a malicious actor could observe a pending anonymous transaction and front-run it with their own.

A hierarchical data structure where each leaf node is a hash of a data block, and each non-leaf node is a hash of its child nodes. Semaphore uses a Merkle tree to efficiently manage and prove membership within an anonymous group.

• Function: The root of the tree serves as the compact, public commitment to the entire group.
• Membership Proof: A user can generate a zero-knowledge proof that they possess a secret corresponding to a leaf in the tree, without revealing which leaf.

A public, on-chain representation of a user's private identity within a Semaphore group. It is generated by cryptographically hashing a user's private identity nullifier and trapdoor. The commitment is stored as a leaf in the group's Merkle tree.

• Key Property: The commitment reveals nothing about the underlying private keys.
• On-Chain Role: Acts as the public anchor for anonymous group membership.

A unique cryptographic hash generated for each anonymous action (or signal) a user makes with Semaphore. Its primary purpose is to prevent double-signaling—ensuring a user cannot broadcast the same signal more than once within a specific context.

• Generation: Derived from a user's private nullifier key and the external nullifier (e.g., a poll ID).
• On-Chain Record: The nullifier is published, allowing contracts to check if it has been used before.

The core organizational structure within the protocol. A group is defined by a Merkle root and allows members to prove they belong without revealing their specific identity.

• Types: Can be on-chain (managed by a smart contract) or off-chain.
• Use Cases: Voting cohorts, anonymous credentials, attestation sets.
• Management: Members can join (add commitment) or leave (through removal or expiration).