Design and Evaluation of a Privacy‑Preserving Decentralised Exchange Using Zero‑Knowledge Proofs
Poh Say Keong
Agenda
Problem & Motivation
Why DEX privacy matters
Research Objectives
5 key questions addressed
System Design
Architecture & protocol
ZK Proof Architecture
Three SP1 programs
Evaluation & Results
Benchmarks vs Uniswap V3
Conclusion
Limitations & future work
What is a Decentralised Exchange?
TRADITIONAL EXCHANGE (CEX)
- Central operator holds custody of funds
- Order book managed off-chain
- Requires KYC and trust in operator
DECENTRALISED EXCHANGE (DEX)
- Smart contract holds custody and no operator is required
- Trades settled on-chain, trustlessly
- Uses AMM: liquidity pools replace order books
AMM price formula
(Automated Market Maker)
x · y = k
Constant product maintained as tokens are swapped between two reserves
Uniswap V3
Dominant DEX · $2.7T cumulative volume
AMM Example: x · y = k
INITIAL POOL STATE
Reserve X (ETH)
100
Reserve Y (USDC)
200,000
k = x · y
20,000,000
User swaps in
+2,000 USDC
AFTER SWAP
New Reserve Y
200,000 + 2,000 = 202,000
New Reserve X
20M ÷ 202,000 = 99.01
ETH received
100 − 99.01 = 0.99 ETH
Effective price
$2,020 / ETH
Larger trades move further along the curve, paying a higher price. This is price impact.
SLIPPAGE
The difference between the expected price and the actual price paid. In this example: expected $2,000/ETH, paid $2,020/ETH — 1% slippage.
Every DEX Trade is
Permanently Public
Order Size
Visible in mempool before confirmation
Execution Price
Slippage tolerance exposed on-chain
Identity
Wallet addresses linkable over time
Enables front-running, MEV extraction, and statistical deanonymisation
Front-Running & MEV
SANDWICH ATTACK
- Monitor mempool for large pending trades
- Insert buy with higher gas (execute first)
- Victim executes at worse price
- Attacker sells for guaranteed profit
BLOCK TRANSACTION ORDER
Attacker BUY
high gas price ↑
Victim SWAP
pays inflated price
Attacker SELL
guaranteed profit ✓
$1B+
Extracted from retail users
$21B → $1.55T
DeFi market 2024 → 2034
Research Objectives
Hide individual trade details while maintaining CFMM correctness
Achieve user anonymity and unlinkability across all protocol phases
Verify state transitions on-chain without revealing private inputs
Can privacy be achieved at lower cost than Uniswap V3?
Characterise the latency/throughput trade-off for batch settlement
Sealed-Bid Batch DEX
Sealed Orders
Encrypted under committee key until batch closes
Unified Price
All orders clear at the same price, no MEV
ZK Settlement
On-chain proof verifies correctness, hides data
Key principle: The prover is a convenience, not an authority. A dishonest prover can only delay; it cannot forge.
Zero‑Knowledge Proofs & SP1
What is Zero-Knowledge?
A prover convinces a verifier that a statement is true without revealing why it is true.
Analogy
Proving you know a password without typing it, the verifier learns only "correct" or "incorrect".
- ✓ Completeness: honest proofs always verify
- ✓ Soundness: false proofs cannot verify
- ✓ Zero-knowledge: verifier learns nothing else
How SP1 Works
SP1 is a zkVM (zero-knowledge virtual machine) by Succinct Labs. Write normal Rust; SP1 generates a ZK proof of correct execution.
Write program logic in Rust (no circuit DSL)
SP1 compiles to a RISC-V trace and proves it with Groth16
On-chain verifier checks a 260-byte proof in constant gas
Result: complex off-chain computation with on-chain trust
Three-Layer Architecture
On-Chain · PrivacyDEX.sol
ERC-20 vault · Merkle root storage · Spent nullifiers · SP1 Groth16 verifier
Off-Chain · Prover
Aggregates orders · Runs CFMM batch · Generates SP1 ZK proofs
User Layer
Deposits/withdraws on-chain · Submits encrypted orders off-chain · Local note storage
Cryptographic Foundation
Two-Hop Key Derivation
ownerPublic = H(ownerSecret)
recipientPattern = H(ownerPublic || salt)
nullifier = H(ownerSecret || salt)
// Token-bound note commitment
noteCommitment = H(value || token || recipientPattern)
Without ownerSecret and salt, observers cannot link any deposit to its output — forward unlinkability.
Incremental Merkle Tree
Tree Depth
20
Max Notes
2²⁰ ≈ 1M
On-chain storage
Root only
Hash function
Keccak256
End-to-End Protocol Flow
Deposit
Token transferred to vault; note commitment stored (pending state)
Order Submission
Encrypted order + nullifier ZK proof sent to prover queue
Batch Matching (off-chain)
Prover computes CFMM batch; generates Groth16 proof
Batch Settlement (on-chain)
Contract verifies proof; updates Merkle root & reserve commitment
Withdrawal
User generates proof locally; redeems tokens without prover involvement
Deposit Phase
- User calls
deposit(amount, token, recipientPattern)on the vault contract - Contract takes custody of tokens
- Note commitment computed and placed in pending pool
- Contract emits
Deposit(noteCommitment, token, amount)
ownerPublic = H(ownerSecret)
recipientPattern = H(ownerPublic || salt)
// Token-bound note commitment
noteCommitment = H(value || token || recipientPattern)
Note sits in pending pool; Merkle root unchanged until batch settles.
Why the Contract Generates the Commitment
If the user computed it
deposit(noteCommitment)
Alice deposits 1 ETH but submits a commitment for 100 ETH:
noteCommitment = H(100 || ETH || recipientPattern)
The ZK circuit only sees the commitment; it cannot know the real deposit was 1 ETH. Alice withdraws 100 ETH.
Contract computes it
deposit(amount, token, recipientPattern)
The contract receives 1 ETH and commits to exactly that:
noteCommitment = H(1 || ETH || recipientPattern)
The circuit asserts the withdrawal amount matches the committed value. Alice can only withdraw 1 ETH.
Why a Pending Pool?
Deposits arrive continuously. The Merkle root is a single on-chain value. Two concurrent insertions would race to update it and one would overwrite the other.
Without pending pool
- Alice deposits → tries to update root
- Bob deposits → also tries to update root
- One transaction overwrites the other
- One note is lost
With pending pool
- Alice and Bob both deposit into the pool
- Root stays unchanged
- Batch settlement inserts all pending notes atomically
- No race condition
The ZK proof for batch settlement commits to the full set of pending insertions, so the Merkle root transition is verified in one atomic on-chain step.
Order Submission
What the user submits
Encrypted order (under committee key)
token_in, amount_in, inputNotes[],
token_out, min_output, recipientPattern
}
Each inputNote
value, token, leafIndex,
merklePath[], nullifier
}
Nullifier ZK proof (SP1 Nullifier Program)
Proves ownership of a committed note without revealing which one
IN: ownerSecret, salt
// SP1 program checks
nullifier = H(ownerSecret || salt)
ownerPublic = H(ownerSecret)
recipientPattern = H(ownerPublic || salt)
// public outputs
OUT: nullifier, recipientPattern
Validating the Input Note
The prover receives the recipientPattern from the nullifier proof. It uses this to regenerate the note commitment and check it against the Merkle tree.
expected = H(value || token || recipientPattern)
// 2. Verify Merkle inclusion
assert( MerkleVerify(expected, leafIndex, merklePath[], root) )
Both recipientPattern and nullifier are public outputs of the SP1 nullifier proof. The prover trusts them without ever seeing ownerSecret.
Batch Matching (Off-chain)
// Loop until stable
loop {
// recompute ΔX, ΔY from remaining orders
R'_X = R_X + ΔX
R'_Y = R_Y + ΔY
// enforce invariant: pair each reserve with its minimum counterpart
// option A: keep R'_X, set R'_Y = k / R'_X
// option B: keep R'_Y, set R'_X = k / R'_Y
// pick the option that leaves more leftover in the pool
p* = R'_Y / R'_X
// remove orders where slippage > tolerance; break if unchanged
}
All traders in the batch receive the same unified clearing price p*. Order sequencing cannot affect outcomes.
Slippage Filtering
Sort orders by slippage tolerance
O(n log n)
Binary search for the cut-off price
O(log n)
Orders are sorted so the binary search can find the cut-off in O(log n). Once p* is known, every order below the cut-off is excluded in one pass.
Example: USDC → ETH, original price 2000, p* = 2010
| Order | Max slippage | Max price | Filled? |
|---|---|---|---|
| Alice | 5% | 2100 | ✓ |
| Bob | 2% | 2040 | ✓ |
| Carol | 0.5% | 2010 | ✓ |
| Dave | 0.1% | 2002 | ✗ |
| Eve | 0.05% | 2001 | ✗ |
Output: valid order set + Groth16 proof
SP1 Batch Settlement Program
Batch Settlement (On-chain)
Checks
assert oldRoot == current merkleRoot
assert ZK proof is valid
assert each depositCommitment is in pending pool
assert each nullifier has not been seen before
State transitions
mark each nullifier as spent
merkleRoot ← newRoot
reserveCommitment ← newReserveCommitment
Withdrawal Phase
What happens
- User generates withdrawal proof locally (no prover involved)
- Circuit re-derives recipientPattern and recomputes noteCommitment; asserts Merkle inclusion
- Circuit derives nullifier from ownerSecret and salt
- User submits proof to contract; contract checks nullifier not spent, then transfers tokens to recipient
Withdrawal program I/O
// SP1 program checks
assert MerkleVerify(noteCommitment, leafIndex, merklePath[], merkleRoot)
nullifier = H(ownerSecret || salt)
// public outputs
OUT: merkleRoot, nullifier, recipient, amount, token
Withdrawal is unlinkable from deposit: recipient address is only revealed at this step and is not tied to any on-chain history.
Three Independent SP1 Programs
Proves correct key derivation. Generated by each user in parallel.
MODE
Verifies CFMM, Merkle insertions, deposits. Recursively verifies n nullifier proofs.
MODE
ON-CHAIN COST
Proves note ownership & Merkle inclusion. No prover involvement required.
MODE
Reserve Privacy
UNISWAP V3
- R_X and R_Y always public
- Pool size and implied price visible to all
THIS SYSTEM
- Only H(R_X ‖ R_Y) stored on-chain
- ZK circuit verifies CFMM invariant holds
- Actual reserves never revealed publicly
C_reserves = H(R_X || R_Y)
// ZK circuit asserts:
assert(H(R_X||R_Y) == C_old)
assert(R''_X * R''_Y == R_X * R_Y)
What Does a BatchSettled Event Reveal?
❌ Visible to Observers
New Merkle root
Count of notes spent
Which deposits confirmed
Reserve commitment hash
✓ Hidden from Observers
Individual commitment values
Which notes were spent
Trade amounts per trader
Actual reserve values R_X, R_Y
Gas Cost per Order vs Batch Size
$0.074
per order (N=128)
$0.375
Uniswap V3 per trade
80%
gas reduction at N=128
N≈3
break-even point
1 gwei gas · ETH @ $2,500 · Fixed Groth16 verification (~270k gas) amortised across batch
This System vs Uniswap V3
| Metric | This System (N=128) | Uniswap V3 |
|---|---|---|
| Gas cost per trade | $0.074 (29,413 gas) | ~$0.375 (150,000 gas) |
| Settlement latency | ~53.8s + 1 block * | ~12s (1 block) |
| Trade privacy | ✓ Full | ✗ None |
| MEV protection | ✓ Structural | ✗ Exposed |
| Front-running protection | ✓ Sealed-bid | ✗ Mempool visible |
Trade-off: higher latency is acceptable for privacy-sensitive applications where minutes-scale finality is tolerable.
* Measured on the SP1 Prover Network
Proof Time: Sublinear Scaling
32× orders
→ only 5.4× more proof time
WHY SUBLINEAR
- SP1 segment-level GPU parallelism
- Fixed setup costs amortised
GPU cost
~$1/hour
NVIDIA L4 · <1% of per-order cost
Layer 2 & Multi-Prover
Layer 2 Deployment (0.01 gwei)
N=128 cost/order
$0.00074
N=2 cost/order
$0.004
Gas is no longer the bottleneck as proof generation time becomes the binding constraint.
Pipelined Multi-Prover
3× throughput with no additional trust assumptions
Open Problems
Operator Trust
Malicious prover can censor or delay, but cannot forge valid settlements
Fee Transparency
Fees deducted out-of-circuit; in-circuit deduction needed for full verifiability
Price Discovery
Hidden reserves create post-settlement arbitrage opportunity
Research Roadmap
Permissionless Proving
Any party submits valid proofs, eliminates trusted prover assumption
In-Circuit Fees
Deduct fees inside ZK circuit for full verifiability
Multi-Prover Protocol
Formal pipelining protocol; continuous batches
Larger Merkle Trees
Beyond depth-20 for production scale
Privacy-Preserving DeFi is Economically Viable
80%
gas reduction vs Uniswap V3 at N=128
5×
cheaper per trade with full privacy
0
order-sequencing MEV (structural)
- Sealed-bid batch DEX with unified clearing price means that front-running is structurally impossible
- Prover-as-convenience: dishonest prover can only delay, never forge
- Three-program SP1 design with recursive nullifier verification
- $0.074/trade at N=128 with full cryptographic privacy guarantees
Thank you — Questions?
Poh Say Keong · NUS School of Computing