Privacy Wallet · Technical Docs

Cryptographic primitives

The math that powers Void

This page summarizes the hash functions, elliptic curve settings, and proof system that make a zkSNARK-based privacy pool practical on Solana.

Summary

Void relies on SNARK-friendly hashing, a pairing-friendly curve, and Groth16 proofs to authenticate shielded transactions while keeping witness data private.

Hash functions

Two hash primitives serve distinct roles: one optimized for circuits and one for general-purpose use outside the proof.

Algorithm
Usage
Reason
VoidHash
Merkle nodes, note commitments, and nullifier computation inside the circuit.
SNARK friendly — far fewer constraints than SHA-style hashes, yielding smaller and faster circuits.
Keccak256
Auxiliary hashing outside the circuit (e.g., deterministic identifiers for emergency nullifiers).
Well-analyzed, broadly supported, and inexpensive when not part of the proof system.

Elliptic curve and field

Curve: BN254 (alt_bn128). A pairing-friendly curve widely used with Groth16, providing efficient pairings for on-chain verification.

Scalar field. All circuit arithmetic is performed in a 254-bit prime field. Public values such as 64-bit lamport amounts are range-checked to avoid overflow.

Groth16 proof system

  • Constant-size proofs. Proofs are a fixed set of group elements, regardless of circuit complexity.
  • Embedded verification key. The Void program ships with a single hard-coded verifying key, avoiding runtime deserialization.
  • Public input schema. Inputs follow a strict ordering (Merkle root, nullifiers, commitments, amounts) so verification remains deterministic.

Trusted setup risk

Groth16 requires a trusted setup ceremony to produce the proving key. If the toxic waste from that ceremony were compromised, an attacker could fabricate proofs that mint value inside the pool. Production deployments must use multi-party setups with public transcripts and independent verification.