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:
- The commitment value is positive in the range of uint240
- The algebraic sum of input amounts must equal the sum of output amounts. 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] => ownerCircuit Library
ZeroLedger supports ten transaction types, proven by separate circuits:
| Circuit | Layout | Approximate browser proving (M1-series laptop) |
|---|---|---|
| deposit | 0 in → 3 out | 1.5 s |
| 1–1 | 1 → 1 | 1.5 s |
| 1–2 | 1 → 2 | 1.7 s |
| 2–1 | 2 → 1 | 1.7 s |
| 1–3 | 1 → 3 | 2.1 s |
| 3–1 | 3 → 1 | 2.0 s |
| 2–2 | 2 → 2 | 2.1 s |
| 2–3 | 2 → 3 | 2.3 s |
| 3–2 | 3 → 2 | 2.2 s |
| 3-3 | 3 → 3 | 2.6 s |
| 8-1 | 8 → 1 | 5.0 s |
| 16–1 | 16 → 1 | 9.0 s |
All circuits share the same Plonk verification key generated from the public BN254 "Powers of Tau" ceremony.
Operations
Deposit
In a deposit operation, the protocol transforms a public token amount into three confidential commitments. Commitments can have a different values (even 0) and be assigned to different owners.
The zero-knowledge proof attests to:
- The sum of the committed hidden amounts equals the deposited value minus fees
- Each committed amount is in the range of uint240
When making a personal deposit, the user typically randomly splits the deposit amount into 3 pieces and creates commitments assigned to the depositor's address. This improves the future payment confidentiality properties.
When a user receives tokens via a one-time usage trustless proxy contract, the protocol produces one commitment assigned to the real recipient, and two 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. The zero-knowledge proof validates:
- Input commitment amounts equal output commitment amounts minus public spending
- Each output commitment amount is in the valid range of uint240
Withdraw
A withdrawal reveals a single commitment's plaintext. The sender supplies the tuple (C, a, γ), the withdrawal recipient address, and signature. The contract recomputes the commitment, verifies the signature, and transfers the amount minus fees.
Trusted Encryption Service
Trusted Encryption Service is a backend service that handles encryption and decryption of private transaction metadata for recipients who have not yet registered their View Accounts in wallet. Additionally, TES manages a set of addresses that can be used as decoy recipients. In default TES implementation, any OFAC compliant wallet address that has ever interacted with protocol can be used as decoy recipient
Decoy Address Selection
- Chooses decoy addresses based on transaction history
- Maintains plausible transaction patterns
- Prevents basic graph analysis attacks