Skip to content

Core Concepts

Commitments

The protocol adopts a classic UTXO perspective: each unspent commitment assigned to ERC20 token address and represents an amount (a) and a randomization factor (γ), committed with Poseidon into a 254-bit identifier that doubles as the storage key.

C = Poseidon(a ∥ γ) ∈ Fℓ

Spending a commitment requires zero-knowledge proof that:

  1. The commitment value is positive in the range of uint208
  2. The algebraic sum of input amounts must be equal or bigger than the sum of output amounts (weak equality). Outputs can be either private (new commitments) or public (ERC-20 transfers)

Ownership Model

Ownership is public: the notes owner field is stored openly in the contract and must match the spend signature owner during a spend:

store[token][commitment] => owner

Operations

Deposit

In a deposit operation, the protocol transforms a public token amount into up to three confidential commitments. Commitments can have different values (including 0) and be assigned to different owners. The deposit operation supports both standard ERC20 transfers and ERC20 permit-based deposits.

The zero-knowledge proof attests to:

  1. The sum of the committed hidden amounts equals the deposited value minus fees (deposit fee and forwarder fee)
  2. Each committed amount is in the range of uint208

The contract enforces a maximum total value locked (maxTVL) per token to prevent exceeding protocol capacity.

When a user receives tokens via a one-time usage trustless proxy contract, the protocol produces one commitment assigned to the real recipient, and zero-value commitments assigned to decoy recipients. This helps to hide the real invoice payment recipient, while keeping the invoicing UX as simple as just paying to some address.

Spend

Spend operations require users to send transactions that burn input commitments in exchange for creating new unspent commitments and/or public ERC20 transfers. The protocol supports multiple input/output combinations: 1-1, 1-2, 2-1, 1-3, 3-1, 2-2, 2-3, 3-2, 3-3, 6-1, and 12-1.

The zero-knowledge proof validates:

  1. Input commitment amounts equal or bigger than output commitment amounts + public output amounts, including fees
  2. Each output commitment amount is in the valid range of uint208
  3. All input commitments are owned by the transaction sender

Spend operations can create both:

  • Private outputs: New confidential commitments assigned to specified owners
  • Public outputs: Direct ERC20 token transfers to recipient addresses

Additionally, spendAndCall allows spending commitments and then calling a recipient contract with custom data, enabling integration with other protocols.

UX enhancements with Service Node

Service Node is a backend infrastructure component that can be run by anyone with own modifications. It provides extra functionality for the ZeroLedger Clients, improving overall user experiences:

Dapp Client (web-app)

The Dapp Client is a web-based application that provides users with a complete interface for interacting with the ZeroLedger protocol. It handles all client-side operations required for private transactions:

Authentication and Authorization: Users sign in with email and connect either a built-in wallet or an external wallet (MetaMask, Coinbase Wallet, Safe Wallet, etc.). The client creates and authorizes a View Account—a separate authentication account that manages encryption keys and handles transaction metadata decryption without having custody of user funds.

Zero-Knowledge Proof Generation: The client generates zero-knowledge proofs locally in the browser for all deposit and spend operations. It uses WebAssembly-based proof generation with pre-loaded circuit files, enabling users to create proofs in seconds without relying on external services.

Transaction Management: Users can deposit public tokens into private commitments, send private commitments to recipients (with optional messages), and view their transaction history. The client handles commitment selection, amount splitting, and decoy recipient integration for privacy.

Real-time Synchronization: The client continuously syncs with the blockchain and Service Node to keep balances and transaction history up-to-date. It processes vault events, decrypts transaction metadata, and maintains a local ledger of all user commitments.

User Interface: The application provides a mobile-first interface with three main tabs: Wallet (for viewing balances and sending), Activity (for transaction history), and Menu (for deposits and settings). All operations include transaction previews, fee displays, and confirmation steps.

Decoy Address Selection

The protocol uses a sophisticated decoy recipient selection mechanism to enhance privacy and prevent graph analysis attacks. When a user sends a payment, the client automatically selects decoy recipients and assigns them small amounts (typically 0.005% of the transaction value) to create plausible transaction patterns.

Local Recipient Pool: The client maintains a local database of addresses that have previously received payments from the user, organized by transaction count. This allows the system to find recipients with similar transaction patterns, making decoy transactions appear more natural.

Hybrid Selection Strategy: The system uses a hybrid approach combining local and remote recipient pools:

  • 80% of the time: Selects candidates from the local recipient pool (addresses with similar transaction counts, within ±5 transactions)
  • 20% of the time: Requests random recipients from Service Node to introduce variability

Activity-Based Weighting: All candidate recipients are evaluated based on their wallet activity ratings provided by Service Node. The system uses weighted random selection where more active wallets have a higher probability of being chosen. This ensures decoy recipients appear realistic and prevents patterns that could reveal the real recipient.

Amount Distribution: The total decoy amount (calculated as a small percentage of the transaction value) is evenly split among selected decoy recipients, with any remainder assigned to the first selected recipient. This creates natural-looking transaction amounts.

Transaction History Tracking: The system continuously updates its local recipient database by tracking all incoming transactions. When a user receives a payment, the sender's address is saved and indexed by transaction count, building a profile of typical transaction patterns over time.

This multi-layered approach ensures that decoy transactions blend seamlessly with real transaction patterns, making it extremely difficult for observers to distinguish between real recipients and decoys through graph analysis or pattern recognition.