Glossary & Reference

Arithmetic on a finite set where operations wrap within the set. All ZERA computations happen over the scalar field of the BN254 curve -- a large prime field where addition, multiplication, and inversion are well-defined.

BN254 scalar field: r ≈ 2^254 (a 254-bit prime)

The elliptic curve used by ZERA's Groth16 proof system. BN254 is a pairing-friendly curve -- it supports bilinear pairings needed for efficient SNARK verification. It's the same curve used by Ethereum's precompiles and is well-supported across proof tooling.

BN254: y² = x³ + 3 over a ~254-bit prime field

A hash function designed specifically for arithmetic circuits (zk-SNARKs). Unlike SHA-256, Poseidon operates natively over finite field elements, requiring far fewer constraints inside a circuit. ZERA uses the X5 variant (fifth-power S-box) for commitments, nullifiers, and Merkle tree hashing.

Commitment = Poseidon(amount, secret, blinding, asset, memo[0..3])

A binary hash tree where each leaf is a commitment and each internal node is the Poseidon hash of its two children. ZERA uses a 24-level tree (2^24 = 16,777,216 leaf capacity). It's "incremental" because leaves are appended left-to-right and the tree is never re-balanced -- only the path from the new leaf to the root is updated.

Inclusion proof: 24 sibling hashes from leaf → root (O(log n))

A cryptographic fingerprint that binds you to a value without revealing it. ZERA uses Poseidon hash-based commitments (not curve-based Pedersen commitments). The commitment is a single field element that hides the amount, secret, blinding factor, asset type, and memo.

Commitment = Poseidon(amount, secret, blinding, asset, memo[0..3])

A unique value derived from your secret and commitment that marks a note as spent. Publishing a nullifier prevents double-spending without revealing which commitment was consumed. In ZERA, nullifiers are stored as Solana PDAs.

Nullifier = Poseidon(secret, commitment)

One-way functions mapping arbitrary input to fixed-length output. ZERA uses Poseidon X5 for all in-circuit hashing (commitments, nullifiers, Merkle tree nodes) because it's optimized for arithmetic circuits over finite fields.

Poseidon: field elements in → single field element out (circuit-friendly)

A path of 24 sibling hashes from a leaf to the Merkle root, proving that a specific commitment exists in the tree. The proof is verified inside the zk-SNARK circuit -- the verifier only sees the root, never the leaf or its position.

Proof path: leaf → 24 siblings → root (verified in-circuit)

A proof system that lets you prove a statement is true without revealing the underlying data. "Succinct" means the proof is tiny (a few hundred bytes). "Non-interactive" means it's a single message -- no back-and-forth. ZERA's circuits produce zk-SNARKs that are verified on Solana.

Proof: "I know a secret and amount that hash to a commitment in the tree" (without revealing them)

The specific zk-SNARK proof system used by ZERA. Groth16 produces the smallest proofs (just 3 group elements on BN254) and has the fastest verification time -- critical for on-chain verification on Solana. Requires a per-circuit trusted setup to generate proving and verification keys.

Groth16 proof: 3 BN254 group elements (~192 bytes), verified in ~1ms on-chain

A JavaScript/WebAssembly library for generating and verifying zk-SNARK proofs. ZERA's web wallet uses snarkjs to generate Groth16 proofs entirely in the browser -- your private inputs never leave your device. The circuits are written in Circom and compiled to WASM for client-side execution.

snarkjs.groth16.fullProve(inputs, wasmFile, zkeyFile) → { proof, publicSignals }

An on-chain smart contract that holds tokens in escrow and manages a Merkle tree of commitments. Users deposit tokens into the pool (creating commitments) and withdraw by proving ownership via zk-SNARKs. While in the pool, all value is shielded -- amounts, owners, and transfer history are hidden.

Deposit → Commitment added to tree | Withdraw → Nullifier published, tokens released

A Solana account address derived deterministically from seeds (no private key). ZERA stores each nullifier as a PDA -- if the PDA already exists, the spend is rejected. This provides O(1) double-spend detection without maintaining a separate database.

PDA = findProgramAddress([nullifier_bytes], program_id)

ZERA's 24-level incremental Merkle tree is stored on Solana. New commitments are appended as leaves, and the root is updated. The Solana program maintains a history of recent roots so that proofs generated a few blocks ago remain valid.

Tree capacity: 2^24 = 16,777,216 leaves | Root history for recent-root validation

The Solana program includes a Groth16 proof verifier that checks BN254 pairing equations. It takes the proof (3 group elements) and public signals (nullifier, Merkle root, output commitments) and returns pass/fail. Verification is fast enough to run within Solana's compute budget.

verify(proof, public_signals, verification_key) → bool

The TypeScript SDK for integrating ZERA shielded payments into any application. Uses a Rust core (zera-core) compiled to WASM for performance-critical operations like Poseidon hashing and proof generation.

npm install @zera-labs/sdk — commitment, proof, Merkle, and transaction APIs

An NFC tag with 888 bytes of user memory -- enough to store a shielded note as an NDEF payload. ZERA uses NTAG216 tags as bearer instruments: whoever physically holds the tag holds the value. Compatible readers include ACR122U, PN532, and most NFC-enabled smartphones.

NDEF payload: { amount, secret, blinding, asset, memo } — readable by tap

ZERA has four Groth16 circuits, each compiled from Circom: deposit (create a commitment), withdraw (prove ownership and release tokens), relayed withdraw (withdraw via a relayer to hide your address), and shielded transfer (move value between notes inside the pool).

Circuits: deposit | withdraw | relayed_withdraw | shielded_transfer

A native desktop application built with Tauri (Rust backend, web frontend). Adds NFC hardware support for reading and writing bearer instruments via USB readers. Designed for point-of-sale, cash-like distribution, and environments where a browser wallet isn't ideal.

Tauri + Rust + WebView — NFC via ACR122U / PN532 USB readers

Groth16 requires a one-time trusted setup ceremony for each circuit. This produces a proving key and verification key. The "toxic waste" (random values used during setup) must be destroyed -- if any participant in the ceremony is honest, the system is secure. ZERA runs a separate setup for each of its four circuits.

Setup → (proving_key, verification_key) per circuit | Toxic waste destroyed

The guarantee that no one can create a valid proof for a false statement. In ZERA, soundness means: you cannot withdraw funds you don't own, create money from nothing, or double-spend a note. The Groth16 proof system provides computational soundness under the BN254 pairing assumption.

Soundness: no polynomial-time adversary can forge a valid proof

The guarantee that the proof reveals nothing beyond the truth of the statement. In ZERA, the verifier (Solana) learns only that the transaction is valid -- not the amount, sender, recipient, or which commitment was spent. The proof is indistinguishable from random data to anyone without the private inputs.

Zero-knowledge: proof reveals ∅ about private inputs (amount, secret, blinding)