🖐️Introduction to Nonce

Nonce introduces a privacy-preserving decentralized finance protocol that enables confidential transactions, swaps, and yield farming on Base Layer 2. By leveraging zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs) with the Groth16 proving system, Nonce allows users to transact with complete anonymity while maintaining the verifiability and security guarantees of public blockchains. The protocol implements a note-based UTXO model where each transaction input and output is represented as a cryptographic commitment, enabling users to prove ownership and execute operations without revealing transaction details to observers. Through integration with existing DeFi protocols via specialized adapter contracts, Nonce provides private access to swaps, lending, and liquidity provision while preserving the composability that defines decentralized finance.

Introduction

The Privacy Paradox in Public Blockchains

Public blockchains achieve decentralization and censorship resistance through radical transparency. Every transaction, every balance, and every interaction with smart contracts becomes permanently recorded in an immutable ledger accessible to anyone. While this transparency enables trustless verification and prevents double-spending, it creates a fundamental privacy problem. When Alice sends tokens to Bob, the blockchain reveals not only the transaction amount but also the complete transaction history and current balance of both parties. This level of financial transparency would be unacceptable in traditional finance, where bank accounts remain confidential and wire transfers do not expose personal wealth to the public.

The privacy implications extend beyond individual discomfort. Traders reveal their strategies to competitors and front-running bots. Large token holders become targets for social engineering attacks and physical threats. Institutional participants cannot execute significant positions without moving markets through their visible on-chain footprint. This transparency tax reduces the utility of public blockchains for real-world financial applications and creates barriers to mainstream adoption.

Existing Privacy Solutions and Their Limitations

Earlier attempts at blockchain privacy have taken various approaches with mixed results. Mixing services like Tornado Cash provide privacy through fixed-denomination pools where users deposit and later withdraw identical amounts, achieving anonymity through the crowd. However, these systems face several limitations. Fixed denominations reduce flexibility and create inefficient capital usage. The mixing model requires users to wait for sufficient pool liquidity to achieve meaningful anonymity sets. Most critically, mixing services provide privacy only for simple transfers and cannot extend to complex DeFi interactions like swaps or yield farming.

Privacy-focused blockchains such as Zcash and Monero implement protocol-level privacy features that hide transaction details by default. While technically sophisticated, these systems require users to adopt entirely new blockchain ecosystems, abandoning the liquidity and application diversity of Ethereum and its Layer 2 networks. The network effects and switching costs make wholesale migration to privacy-focused chains impractical for most users who require access to established DeFi protocols.

The Nonce Approach

Nonce takes a different path by building privacy as an application layer on top of Base, an Ethereum Layer 2 network. Rather than requiring users to leave the Ethereum ecosystem, Nonce creates privacy pools that integrate directly with existing DeFi protocols. Users can shield assets into these pools, perform private operations including transfers, swaps, and yield farming, and unshield back to public addresses when needed. This approach preserves compatibility with the broader DeFi ecosystem while providing strong privacy guarantees through zero-knowledge cryptography.

The core innovation lies in the adapter system that allows privacy pool contracts to interact with external protocols on behalf of users without revealing individual positions. When a user wants to swap tokens privately, the privacy pool temporarily unshields the input tokens, executes the swap on a decentralized exchange, and immediately re-shields the output tokens. To observers, this appears as a single action by the privacy pool contract, providing no information about which user initiated the swap or the amounts involved. The zero-knowledge proof system ensures that only users who legitimately own funds within the privacy pool can authorize such operations.

Cryptographic Foundations

Zero-Knowledge Proof Systems

Zero-knowledge proofs represent one of the most powerful tools in modern cryptography, allowing a prover to convince a verifier that a statement is true without revealing any information beyond the truth of the statement itself. In the context of Nonce, this means a user can prove they own sufficient funds to execute a transaction without revealing their account balance, transaction history, or identity.

More formally, a zero-knowledge proof system consists of three algorithms: Setup, Prove, and Verify. The Setup algorithm generates public parameters, the Prove algorithm produces a proof π for a statement x using witness w, and the Verify algorithm checks the proof's validity. For a proof system to be useful in blockchain applications, it must satisfy three properties: completeness, soundness, and zero-knowledge.

Completeness requires that an honest prover with a valid witness can always convince an honest verifier. Mathematically, if the statement x is true and the prover knows witness w such that R(x,w) = 1 for some relation R, then Verify(x, Prove(x,w)) = 1 with overwhelming probability. Soundness ensures that a malicious prover cannot convince a verifier of a false statement except with negligible probability. Even if the prover has unlimited computational power, if x is false, then for any proof π*, Verify(x, π*) = 0 with overwhelming probability. Zero-knowledge means the proof reveals nothing beyond the truth of the statement, formally captured through the existence of a simulator that can produce indistinguishable proofs without knowing the witness.

The Groth16 Proof System

Nonce implements privacy using the Groth16 proof system, which offers several advantages for blockchain applications. Groth16 produces constant-size proofs consisting of only three elliptic curve elements regardless of circuit complexity, making verification extremely gas-efficient on Ethereum Virtual Machine chains. A Groth16 proof for a circuit with millions of constraints requires only about 200 bytes of data and can be verified in constant time through a small number of pairing operations.

The Groth16 construction works over bilinear groups. Let (G₁, G₂, Gₜ) be groups of prime order p with a bilinear pairing e: G₁ × G₂ → Gₜ. The proving system represents computations as arithmetic circuits over the finite field Fₚ, specifically as Rank-1 Constraint Systems (R1CS). An R1CS consists of three matrices A, B, C where each constraint takes the form (A·w) ⊙ (B·w) = (C·w), with w being the witness vector containing both public inputs and private witness values.

The Setup algorithm performs a trusted ceremony to generate proving key pk and verification key vk. This ceremony involves sampling random field elements (τ, α, β, γ, δ) and computing various combinations of these with the circuit matrices encoded as elliptic curve points. The toxic waste (τ, α, β, γ, δ) must be securely destroyed after setup, as anyone knowing these values could generate false proofs. The Prove algorithm takes the proving key and witness to compute a proof π = (A, B, C) where A ∈ G₁, B ∈ G₂, and C ∈ G₁. The Verify algorithm checks the proof by evaluating a pairing equation e(A,B) = e(α·β, γ⁻¹)·e(L, γ⁻¹)·e(C, δ⁻¹) where L encodes the public inputs.

Poseidon Hash Function

Traditional cryptographic hash functions like SHA-256 prove extremely inefficient when computed inside zero-knowledge circuits because they were designed for classical computation, not arithmetic circuits over finite fields. Nonce uses the Poseidon hash function, specifically designed for efficient use in zero-knowledge proof systems. Poseidon operates natively over prime fields and requires significantly fewer constraints compared to traditional hash functions.

The Poseidon construction uses a sponge design with a width of t field elements. The state undergoes a series of rounds alternating between full rounds and partial rounds. Each round applies an S-box operation (typically x⁷ for a field element x), adds round constants, and performs a linear mixing through matrix multiplication. Full rounds apply the S-box to all state elements, while partial rounds apply it only to one element to optimize constraint count. For a state (x₀, x₁, ..., xₜ₋₁), the S-box and mixing give x'ᵢ = Σⱼ Mᵢⱼ·(xⱼ + cⱼ)⁷ where M is the MDS matrix and cⱼ are round constants.

Poseidon's security relies on the algebraic difficulty of solving systems of polynomial equations over finite fields. The number of rounds is calibrated based on cryptanalysis against algebraic attacks including Gröbner basis methods and interpolation attacks. For the BN254 curve used in Nonce (with a field of approximately 254 bits), Poseidon with width 3 uses 8 full rounds and 56 partial rounds, requiring only about 152 constraints in R1CS form compared to over 25,000 constraints for SHA-256.

Commitment Schemes and Nullifiers

The privacy model in Nonce relies heavily on cryptographic commitments and nullifiers. A commitment allows a user to commit to a value without revealing it, with the ability to later open the commitment and prove what value was committed. Nonce uses Poseidon-based commitments for efficiency in zero-knowledge circuits.

For a note with value v, token address t, owner's public key pkₒ, and random blinding factor ρ, the commitment is computed as cm = Poseidon(v, t, pkₒ, ρ). This commitment gets stored in the privacy pool's Merkle tree, representing a user's private balance. The randomness ρ ensures that even identical notes produce different commitments, preventing observers from correlating commitments based on their values.

When spending a note, the user must prevent double-spending while maintaining privacy. Nullifiers solve this problem. A nullifier is deterministically derived from the note and the user's private key but appears random to anyone else. For a note with commitment cm and owner's private key skₒ, the nullifier is nf = Poseidon(cm, skₒ). When a note is spent, its nullifier is revealed and stored in a nullifier registry. Since nullifiers are deterministic, any attempt to spend the same note twice produces the same nullifier and gets rejected. However, nullifiers reveal no information about which commitment was spent or who spent it because they depend on the private key unknown to observers.