Protocol Deep Dive

UTXO model, note structure, nullifiers, Merkle trees, and transaction lifecycle

This document explains the core protocol mechanics: how notes work, what commitments and nullifiers are, how the Merkle tree stores state, and what happens step-by-step during deposits, transfers, and withdrawals.

Prerequisites: Familiarity with EVM smart contracts, hash functions, and Merkle trees. Basic understanding of what a zero-knowledge proof does (proves a statement without revealing the witness).

---

The UTXO Model

Privacy Boost uses a UTXO (Unspent Transaction Output) model. Instead of maintaining account balances, the system tracks individual notes — each representing a specific amount of a specific token owned by a specific user.

Think of it like cash. You don’t have a “balance of $47” — you have a $20 bill, a $20 bill, a $5 bill, and two $1 bills. To pay someone $15, you hand over the $20 and get $5 back as change.

In Privacy Boost:

• Spending a note publishes a nullifier (marks it as consumed)
• Receiving creates new notes (adds commitments to the Merkle tree)
• A transfer consumes input notes and creates output notes, with the ZK circuit enforcing that inputs = outputs + fees

---

Notes and Commitments

What’s Inside a Note

A note contains three fields:

Field	Description
NPK (Note Public Key)	Unique per-note key derived from the owner’s identity + randomness
Token ID	Which ERC-20 token (compact ID from the TokenRegistry)
Value	Amount of tokens

The NPK is derived from the owner’s Master Public Key (MPK) and a per-note random value:

MPK = Poseidon2(accountId, nullifyingKey)
NPK = Poseidon2(MPK, noteRnd)

All Poseidon2 hashes in the protocol use domain separators to prevent cross-context collisions — the Glossary lists the specific values.

The per-note randomness ensures that even if the same user receives the same token and amount twice, the resulting commitments are different.

Commitments

A commitment is the Poseidon2 hash of a note’s contents:

Commitment = Poseidon2(NPK, tokenId, value)

This is what gets stored onchain as a Merkle tree leaf. It reveals nothing about the note’s contents — an observer sees only a 256-bit hash. The 128-bit randomness in NPK makes brute-force inversion computationally infeasible.

---

Nullifiers

A nullifier is a one-time-use tag that marks a specific note as spent. It prevents double-spending without revealing which note was consumed.

How Nullifiers Work

Each nullifier is derived from the user’s secret nullifying key and the note’s position in the Merkle tree:

Nullifier = Poseidon2(nullifyingKey, leafIndex)

The tree number is encoded in the hash domain to prevent cross-tree collisions.

An observer sees commitments going in and nullifiers coming out, but can’t link them — the nullifier depends on a secret key and a leaf index, while the commitment depends on NPK, token, and amount. There’s no algebraic relationship between the two.

The contract enforces uniqueness: each nullifier can only be recorded once, preventing double-spending.

How Ownership Is Proven

To spend a note, you prove three things inside the ZK circuit:

1. You know the note’s secrets: The circuit verifies your private fields hash to the correct commitment.
2. Your auth key is registered: You sign with your EdDSA auth key, and the circuit proves it exists in the AuthRegistry.
3. The note exists: The circuit verifies a Merkle proof for your commitment.

All three checks happen in zero knowledge — the contract sees only the proof result, the nullifiers, and the new output commitments. It never learns which note was spent, who signed, or what the amounts were.

---

Merkle Trees

LeanIMT (Lean Incremental Merkle Tree)

All note commitments are stored in an append-only Merkle tree using Poseidon2 hashing. Privacy Boost uses LeanIMT — a Lean Incremental Merkle Tree optimized for efficient onchain appends, minimizing the number of hash computations per insert.

Each tree has a maximum depth of 20 (~1M leaves). Leaves are never modified or deleted.

Multi-Tree Architecture

When the active tree fills up, a new tree is created (rollover). Input notes can reference commitments in any historical tree, so old notes remain spendable indefinitely.

Each tree maintains a ring buffer of recent roots, allowing proofs to reference slightly stale roots. This accommodates the delay between proof construction and onchain submission.

Tree Transitions in Circuits

When new notes are created, the ZK circuit proves that the tree state transition is valid — the contract just verifies the proof and updates the stored root. This means the contract never has to compute Poseidon2 hashes onchain for leaf insertions.

---

Transaction Lifecycle

Deposit (Public → Shielded)

Deposits are a 2-step process:

1. User locks tokens: The user computes note commitments, encrypts the metadata using the dual-path ECDH scheme, and submits everything to the contract. The contract transfers the ERC-20 tokens and stores the pending deposit with replay protection.

2. TEE processes the batch: The TEE detects pending deposits, generates a Groth16 proof verifying that commitments are correctly computed and the tree state transition is valid, then submits it onchain.

Cancellation: If the TEE doesn’t process a deposit within the cancel delay period, the depositor can reclaim their tokens.

Transfer (Shielded → Shielded)

Transfers move value between shielded notes. Sender identity, recipient identity, token type, and amounts are all hidden from onchain observers.

1. User prepares: Select input notes to spend, construct output notes for the recipient (and change for yourself), sign with your EdDSA auth key, and encrypt the output metadata using dual-path ECDH
2. User submits to TEE: The TEE verifies the signature and ciphertext integrity, then batches the transfer into an epoch
3. TEE submits epoch: The TEE generates a Groth16 proof covering signature validity, note existence, nullifier correctness, value conservation, and tree state transition — then submits it onchain
4. Contract verifies: Checks the proof, marks nullifiers as spent, updates the tree root

How the recipient discovers the transfer: The TEE decrypts the output ciphertexts and indexes the new notes. The recipient queries their balance from the TEE indexer. For manual recovery, the recipient can also decrypt the onchain ciphertext independently using their viewing key.

Withdrawal (Shielded → Public)

Withdrawals use the same mechanism as transfers. The difference: instead of creating an output note, the contract sends ERC-20 tokens to a public address. Withdrawals are batched alongside transfers in the same epoch.

Forced Withdrawal (Emergency Exit)

Forced withdrawal is the self-custody escape hatch — exit the shielded pool without any TEE involvement.

1. Reconstruct your notes: Scan onchain events and decrypt metadata with your viewing key
2. Generate a ZK proof locally: Prove you own the notes and derive correct nullifiers — this runs on consumer hardware
3. Submit to the contract: The contract verifies the proof and starts a configurable delay period
4. Execute after the delay: The contract transfers your tokens

Why the delay? It gives the account owner time to cancel unauthorized requests (e.g., from a compromised device) and allows the TEE to process any racing normal transactions.

---

Epoch Batching

Multiple user transactions are aggregated into a single epoch — one Groth16 proof covering the entire batch. This is a key design choice for throughput:

• Groth16 verification costs ~200K gas, regardless of batch size
• Batching amortizes this cost across all participants
• At Base’s gas target, this enables 300+ sustained TPS; at the gas limit, 1,800+ TPS

Epochs are submitted when the batch reaches the configured size. Transfers are not instant — they settle when the epoch is submitted onchain.

To prevent key rotation attacks during an epoch, the contract periodically snapshots the AuthRegistry state. Epoch proofs reference a specific snapshot.

---

Fee Model

• Deposits are fee-free
• Transfers and withdrawals charge configurable fees (in basis points)
• The ZK circuit enforces conservation: inputs = outputs + fees
• Forced withdrawal fees are deducted at execution time

---

Smart Contracts

Contract	Role
PrivacyBoost	Core shielded pool: Merkle trees, nullifier registry, deposits, epochs, forced withdrawals
AuthRegistry	Binds account IDs to EdDSA signing keys. Supports multi-device, rotation, and revocation. Maintains its own Poseidon2 Merkle tree with snapshots for epoch proofs.
TokenRegistry	Maps compact token IDs to ERC-20 addresses (append-only)
AuditGateway	Auditor registry and onchain audit logging (see Compliance)
Groth16 Verifiers	Proof verification for each circuit type (Epoch, Deposit, ForcedWithdraw)

All core contracts are deployed behind upgrade proxies.

---

Next Steps

• Keys & Encryption — How keys are derived and how the dual-path ECDH encryption scheme works
• Trust & Security — TEE guarantees and the full trust model
• Glossary — Technical terminology reference