← Back to writing

Building a Confidential DEX on Solana

4 min read

The Problem

DeFi traders on Solana had zero privacy. Order amounts, prices, and trading patterns were fully visible on-chain, exposing them to front-running, sandwich attacks, and activity correlation. Every order book was completely transparent. If you placed a large buy order, anyone watching the chain could see it, front-run it, and profit at your expense.

This is not a theoretical risk. MEV extraction on Solana was hitting traders daily, and there was no existing solution that preserved privacy without sacrificing performance.

Why Existing Solutions Failed

Most privacy protocols take one of two approaches: encrypt everything and decrypt at execution time, or use a mixing service to obscure origins. Both have problems.

Encrypt-then-decrypt is fundamentally weak for order matching. The moment you decrypt to compare prices, the data is exposed. Mixing services add latency and only hide origin, not order details.

What I wanted was something different: a system where orders could be matched on encrypted data, where prices are compared without ever being revealed.

The Architecture

I built CONFIDEX using a two-layer privacy architecture:

  • Arcium MPC for execution. Orders are matched using multi-party computation. Two parties jointly compute whether a buy price meets a sell price without either party learning the other's number. This is fundamentally stronger than encrypting then decrypting for matching.
  • Light Protocol ZK Compression for settlement. On-chain balances are stored using ZK Compression, which eliminates Solana rent costs entirely. This gave us a 400x savings on storage compared to standard accounts.
  • Bulletproof range proofs for compliance. Users can prove their transaction amounts are within allowed bounds, and prove KYC/AML eligibility, without revealing identity or exact values.

The key insight: privacy and compliance are not opposites. ZK proofs let you prove eligibility without revealing identity.

Technical Decisions

Arcium MPC over standard ZK proofs for the execution layer. MPC allows orders to be matched on encrypted data without ever decrypting. Standard ZK proofs would require one party to see the plaintext at some point in the matching pipeline. With MPC, no single party ever sees both sides of a trade.

Hash-based order IDs and hour-precision timestamps to prevent activity correlation. If you use sequential IDs or precise timestamps, an observer can correlate orders across time even without seeing amounts. Hashing the order data and rounding timestamps to the nearest hour breaks this correlation chain.

WebSocket trading interface for real-time order flow. The frontend connects via WebSocket to receive encrypted order book updates and submit trades without HTTP round-trips.

The Hard Part

Making encrypted order matching performant enough for real-time trading was the main challenge. MPC protocols are computationally expensive. A naive implementation would add 10+ seconds per trade.

I optimised the MPC batch verification pipeline to handle liquidation checks on encrypted positions without revealing entry prices. This is a problem most privacy protocols avoid entirely, they just skip liquidations or expose prices during the check. We batch multiple order comparisons into a single MPC round, amortising the cryptographic overhead across trades.

The result: sub-3-second proof generation for a complete trade cycle.

The Process

Started by researching the privacy gaps in existing Solana DEXs. Mapped every point where trader data was exposed: order placement, price discovery, settlement, and position management.

Designed the two-layer architecture: Arcium MPC for execution (encrypted order matching) and a custom settlement layer using ShadowWire for encrypted on-chain balances. Built the smart contracts in Rust, the WebSocket trading interface in TypeScript, and the privacy infrastructure end-to-end.

Submitted to the Solana Privacy Hack 2026.

What I Learned

Privacy and compliance are not opposites. The best privacy systems are the ones regulators can trust too. ZK proofs make this possible: you can prove you are eligible to trade (KYC/AML) without revealing who you are or what you are trading.

The other lesson: performance constraints force better architecture. If MPC was instant, I would have built a simpler system. The 3-second budget forced me to design batching, pipelining, and caching strategies that made the overall system more resilient.

Stack

React, TypeScript, Solana, Rust, Node.js, WebSockets, Arcium MPC, Light Protocol, Bulletproof proofs.