Glossary

This glossary defines the key terms used throughout the ZKMix documentation. Terms are listed in alphabetical order.

Anonymity Set

The set of all deposits in a pool that a given withdrawal could plausibly originate from. When a user withdraws, observers know only that the withdrawal corresponds to one of the deposits in the anonymity set, but not which one. The size of the anonymity set is the primary measure of privacy strength. A pool with 10,000 deposits provides an anonymity set of 10,000, meaning an attacker's best guess at linking a withdrawal to a deposit has a 1-in-10,000 chance of being correct.

Arithmetic Circuit

A mathematical representation of a computation expressed as a series of addition and multiplication gates over a finite field. Zero-knowledge proof systems like Groth16 operate on arithmetic circuits. The ZKMix circuit encodes the logic for verifying Merkle membership and computing hashes, translated into a system of polynomial constraints that the prover must satisfy.

Commitment

A cryptographic value computed from the secret and nullifier during deposit. In ZKMix, the commitment is defined as PoseidonHash(nullifier, secret). The commitment is stored on-chain in the Merkle tree and serves as the public representation of a deposit. Because Poseidon is a one-way function, the commitment reveals nothing about the underlying secret or nullifier.

Compute Budget

The maximum amount of computation a Solana transaction is allowed to consume, measured in compute units. ZKMix withdrawal transactions require elevated compute budgets because on-chain Groth16 proof verification involves expensive elliptic curve operations. The ZKMix client automatically requests the appropriate compute budget when constructing withdrawal transactions.

Denomination

The fixed amount of tokens that must be deposited into and withdrawn from a specific ZKMix pool. All deposits and withdrawals in a pool use the same denomination, such as 1 SOL, 10 SOL, or 1,000 USDC. Fixed denominations prevent amount-based correlation between deposits and withdrawals and are essential for maintaining privacy.

Groth16

A zero-knowledge proof system published by Jens Groth in 2016. Groth16 produces the smallest proofs (three elliptic curve group elements, approximately 192 bytes) and the fastest verification times among widely deployed ZK-SNARK constructions. Its main limitation is the requirement for a circuit-specific trusted setup ceremony. ZKMix uses Groth16 for its proof system because the small proof size and fast verification are critical for on-chain verification within Solana's compute budget constraints.

Incremental Merkle Tree

A variant of a Merkle tree optimized for append-only workloads. Instead of recomputing the entire tree when a new leaf is inserted, an incremental Merkle tree stores intermediate hash values along the rightmost path, allowing new leaves to be added with only O(depth) hash computations. ZKMix uses an incremental Merkle tree of depth 20 (supporting up to 1,048,576 leaves) to store deposit commitments on-chain.

Leaf

A node at the bottom level of a Merkle tree. In ZKMix, each leaf corresponds to a single deposit commitment. When a deposit is made, the commitment is inserted as the next available leaf in the incremental Merkle tree.

Merkle Path

The sequence of sibling hashes from a leaf node up to the root of a Merkle tree. A Merkle path, combined with the leaf value and the left/right position at each level, is sufficient to recompute the Merkle root and prove that the leaf is a member of the tree. In ZKMix, the Merkle path is a private input to the ZK circuit and is used to prove deposit membership without revealing which leaf the prover owns.

Merkle Root

The single hash value at the top of a Merkle tree that summarizes all leaves. Any change to any leaf results in a different root. In ZKMix, the Merkle root is stored on-chain and serves as a compact representation of all deposits. During withdrawal, the prover demonstrates that their commitment is a leaf in a tree with a known root.

Mixer

A protocol or application that pools funds from multiple users and allows withdrawals that cannot be linked to specific deposits. ZKMix is a mixer that uses zero-knowledge proofs to achieve cryptographic unlinkability rather than relying on a trusted intermediary. The term "mixer" is used broadly in the cryptocurrency space to describe any service that improves transaction privacy by breaking the on-chain link between sender and receiver.

Note

A string generated during the deposit process that encodes the user's secret and nullifier. The note is the only piece of information needed to withdraw funds from ZKMix. It is generated client-side and never transmitted to any server or stored on-chain. Losing the note means permanently losing access to the deposited funds. In ZKMix, notes follow the format zkmix-{token}-{version}-{base58(nullifier + secret)}.

Nullifier

A random value generated alongside the secret during the deposit process. The nullifier's purpose is to prevent double-spending. During withdrawal, the hash of the nullifier is revealed publicly, and the smart contract records it. Any subsequent withdrawal attempt using the same nullifier hash is rejected. The nullifier itself remains private; only its hash is published.

Nullifier Hash

The Poseidon hash of the nullifier, computed as PoseidonHash(nullifier). The nullifier hash is a public output of the ZK proof and is recorded on-chain during withdrawal. It serves as a unique identifier for a spent deposit. Because Poseidon is a one-way function, the nullifier hash cannot be reversed to obtain the nullifier, and it cannot be linked to the corresponding commitment without knowledge of both the nullifier and the secret.

Poseidon Hash

A cryptographic hash function designed for efficient use in zero-knowledge proof arithmetic circuits. Unlike general-purpose hash functions such as SHA-256 or Keccak, which rely on bitwise operations, Poseidon operates using only field additions and multiplications, making it highly efficient when expressed as arithmetic circuit constraints. ZKMix uses Poseidon for all hashing operations: commitment computation, nullifier hashing, and Merkle tree node hashing.

Proof

In the context of ZKMix, a proof is a Groth16 zero-knowledge proof that demonstrates the prover knows a valid secret and nullifier corresponding to a commitment in the Merkle tree, without revealing which commitment or the secret values. The proof consists of three elliptic curve points (commonly labeled A, B, and C) and is verified on-chain using the verification key. Proof generation happens client-side and typically takes 5 to 20 seconds.

Proving Key

A cryptographic key generated during the trusted setup ceremony that is used by the prover to generate zero-knowledge proofs. The proving key is specific to the ZKMix circuit and is distributed to all users. It is a large file (typically tens of megabytes) that encodes the circuit structure in a form suitable for proof computation. The proving key does not contain any secret information.

Public Input

A value that is visible to both the prover and the verifier in a zero-knowledge proof. In ZKMix, the public inputs are the Merkle root, nullifier hash, recipient address, relayer address, and fee. These values are submitted on-chain alongside the proof and are used by the verifier to confirm that the proof pertains to the correct statement.

Relayer

A third-party service that submits withdrawal transactions on behalf of users. Relayers solve the bootstrapping problem: a fresh recipient wallet has no SOL to pay transaction fees, and funding it from the deposit wallet would create a traceable link. The relayer submits the transaction and pays the fee, which is reimbursed from the withdrawn amount by the smart contract. Relayers cannot steal funds or learn which deposit is being withdrawn because the recipient and fee are cryptographically bound into the proof.

Secret

A random value generated during the deposit process, used alongside the nullifier to compute the commitment. The secret is part of the private witness in the ZK proof and is never revealed publicly. Together with the nullifier, it forms the note that the user must store securely to later withdraw funds.

SNARK

Succinct Non-Interactive Argument of Knowledge. A class of cryptographic proof systems where proofs are small (succinct), do not require interaction between prover and verifier (non-interactive), and guarantee that the prover possesses the claimed knowledge (argument of knowledge). Groth16 is a specific SNARK construction used by ZKMix.

Solana

A high-performance layer-1 blockchain that uses a proof-of-stake consensus mechanism and achieves high throughput through parallel transaction processing. ZKMix is deployed on Solana to take advantage of its sub-second block times, low transaction fees (typically under $0.01), and high availability. Solana programs are written in Rust and compiled to BPF bytecode.

SPL Token

The standard token format on Solana, defined by the SPL Token Program. SPL tokens are analogous to ERC-20 tokens on Ethereum. ZKMix supports mixing SPL tokens (such as USDC and USDT) in addition to native SOL. Each SPL token and denomination combination has its own independent mixing pool.

Trusted Setup

A one-time cryptographic ceremony required by the Groth16 proof system to generate the proving and verification keys. During the ceremony, participants contribute randomness, and the security of the system depends on at least one participant honestly destroying their secret contribution (known as "toxic waste"). If even one participant is honest, no one can forge proofs. ZKMix's trusted setup was conducted with over 100 participants, and the ceremony transcripts are publicly verifiable.

Verification Key

A cryptographic key generated during the trusted setup ceremony that is stored on-chain and used to verify zero-knowledge proofs. The verification key is small (a few hundred bytes) and allows the smart contract to check the validity of a Groth16 proof in constant time. Unlike the proving key, the verification key must be available on-chain for the protocol to function.

Witness

The complete set of private and public inputs to a zero-knowledge proof circuit. In ZKMix, the witness includes the secret, nullifier, Merkle path elements, Merkle path indices (private inputs), and the Merkle root, nullifier hash, recipient, relayer, and fee (public inputs). The witness is constructed client-side and used to generate the proof. Private witness values are never transmitted or stored on-chain.

Withdrawal

The process of removing funds from a ZKMix pool by generating and submitting a zero-knowledge proof. During withdrawal, the user provides a proof that they know the secret and nullifier behind a commitment in the Merkle tree, along with the nullifier hash. The smart contract verifies the proof, records the nullifier hash to prevent reuse, and transfers the denomination amount to the specified recipient address.

Zero-Knowledge Proof

A cryptographic method by which one party (the prover) can demonstrate to another party (the verifier) that a given statement is true without conveying any additional information. In the context of ZKMix, the prover demonstrates "I made a deposit into this pool" without revealing which deposit, when it was made, or from which address. Zero-knowledge proofs are the foundational technology that makes privacy-preserving mixers possible without requiring trust in a central party.

ZK-SNARK

Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. The specific type of zero-knowledge proof used by ZKMix. ZK-SNARKs combine zero-knowledge (the verifier learns nothing beyond the statement's truth), succinctness (proofs are small and fast to verify), non-interactivity (no communication between prover and verifier after setup), and extractability (the prover must actually know the witness, not just that it exists). ZKMix uses the Groth16 ZK-SNARK construction for its optimal proof size and verification speed.