Inside KalqiX: How We Built a ZK-Powered Trading Infrastructure From First Principles
By Nitin Sharma, Co-Founder and CTO of KalqiX
Building tech is my ikigai. It's not a hobby or a career choice. It's the thing that makes everything else make sense. And KalqiX is the hardest, most rewarding engineering challenge I've ever taken on.
When Sameep first laid out the thesis for KalqiX, the question wasn't whether a ZK-powered order book DEX was a good idea. The answer was obvious. The question was whether it was actually buildable. Could you match orders in under 10 milliseconds, generate zero-knowledge proofs for every trade batch, and settle everything on-chain, without compromising on any of those three things?
This blog is about how we answered that question. Not the marketing version. The engineering version.
The Problem, Through an Engineer's Eyes
Most discussions about DeFi trading problems focus on what traders experience: slippage, MEV, custody risk. Those are real problems. But as an engineer, I see them differently. They're symptoms of architectural decisions, not user experience failures.
AMMs use constant product formulas (x*y=k) to determine price. This is elegant and simple, but it means every trade moves the price curve, creating predictable slippage on larger orders. There's no concept of order priority, price levels, or matching logic. The math does the work, and the math has known limitations.
Public mempools broadcast every pending transaction before execution. This isn't a bug, it's how blockchains achieve consensus. But for trading, it means every order is visible to everyone before it settles. MEV bots exploit this by inserting transactions before and after yours, extracting value from the price movement your trade creates.
The engineering challenge was clear: build a system that gives traders order book functionality (price-time priority, limit orders, real depth) with cryptographic guarantees that every match is fair, private, and verifiable. Without trusting a centralized operator. Without exposing order intent.
The Architecture: Four Layers That Work Together
KalqiX is built as a vAPP, a verifiable application. That means every critical operation produces a cryptographic proof that anyone can verify independently. Here's how the layers connect.
Layer 1: Private Order Submission
When a trader submits an order on KalqiX, it's encrypted before it leaves their client. The order goes to our sequencer in encrypted form. There is no public mempool. No other participant, no bot, no validator, can see the order's intent, price, or size before it's matched.
This is the first architectural difference from both AMMs (where trades are public by default) and most CLOB DEXes (where order flow is visible to the sequencer operator at minimum). On KalqiX, the order flow is private until settlement.
Layer 2: The Matching Engine
This is where I spent the most time and lost the most sleep.
Our matching engine is written in Rust. The choice of Rust wasn't aesthetic. It was driven by three requirements: deterministic execution (no garbage collection pauses), memory safety (critical for financial systems), and raw throughput.
The engine uses price-time priority matching, the same model used by NYSE, NASDAQ, and every major professional trading venue. Orders are matched at the best available price, with earlier orders at the same price level getting priority. This is fundamentally different from AMMs, where there's no concept of order queue or price levels.
We benchmarked the engine at sub-10 millisecond matching latency and 250,000+ transactions per second. Those numbers hold under load because the architecture is built on Rust-based microservices that isolate matching logic from proof generation and settlement.
The matching happens off-chain. This is a deliberate design choice. On-chain matching at this speed is not feasible with current blockchain throughput. But "off-chain matching" only works if you can prove that the matching was done correctly. That's where ZK comes in.
Layer 3: ZK Proof Generation
Every batch of matched trades is converted into a zero-knowledge proof using SP1. The proof cryptographically verifies that: orders were matched according to price-time priority rules, no orders were front-run or reordered for advantage, the final settlement state is correct, and the matching engine didn't manipulate execution.
The proof doesn't reveal the individual orders or their details. It proves the correctness of the output without exposing the inputs. This is what makes KalqiX a vAPP: verifiable execution with private inputs.
SP1 was our choice for the proving system because of its developer experience and performance characteristics. The proof generation runs as a separate service from the matching engine, so proof latency doesn't affect matching speed. Trades are matched instantly; proofs are generated asynchronously and submitted for on-chain verification.
Layer 4: On-Chain Settlement
The ZK proofs are submitted to a verifier smart contract on Base. The contract verifies the proof and updates the on-chain state accordingly. This is where the trade becomes final and immutable.
We use Base for settlement because of its throughput, cost profile, and ecosystem alignment. Data availability runs through Avail, ensuring that all transaction data is publicly accessible and independently verifiable, even though individual order details remain private.
The result: traders interact with a fast, familiar order book interface. Behind the scenes, every trade is cryptographically verified and settled on-chain. Users keep full custody of their funds throughout. No trusted intermediary holds assets at any point.
The Hard Parts Nobody Talks About
Building a ZK-powered matching engine sounds clean on paper. In practice, three engineering problems consumed most of our time.
Proof generation latency vs. matching speed. The matching engine needs to be fast. Proof generation is computationally expensive. If you make them sequential, your system is only as fast as the slowest step. We solved this by decoupling them entirely. Trades match in real time. Proofs are batched and generated asynchronously. Settlement happens when the proof is ready. This means there's a short window between matching and on-chain finality, but at no point is a user's custody at risk.
Deterministic execution across distributed systems. The matching engine must produce identical results regardless of which node processes the orders. Any non-determinism means the ZK proof won't verify. Rust's ownership model helped here, eliminating an entire class of concurrency bugs that could cause state divergence.
Balancing privacy with verifiability. ZK proofs are powerful, but designing the right circuit is an art. You need to prove enough to guarantee fairness without revealing so much that you compromise privacy. Every field we include in the proof is a tradeoff. We iterated through dozens of circuit designs before landing on one that proves matching correctness while keeping order details private.
The Testnet Proved It Works
Testnet wasn't a demo. It was a stress test.
87.7 million transactions. 44.4 million orders processed. 34 million trades executed. 6,248 users. And the number I'm most proud of: zero MEV events. Not low MEV. Zero.
That number isn't marketing. It's the direct result of the architecture. If order flow is encrypted and matching is proven fair via ZK proofs, there's no mechanism for MEV extraction. It's not mitigated. It's eliminated by design.
What's Next
Mainnet is approaching. The architecture is proven. The infrastructure is ready.
Post-mainnet, we're expanding into perpetual futures with the same ZK-proven execution model. The Citrea partnership brings KalqiX's infrastructure to Bitcoin's security model via their ZK Rollup. And the white-label model means every new exchange that launches on KalqiX's engine benefits from, and contributes to, the same shared liquidity pool.
Building tech is my ikigai. KalqiX is the culmination of everything I believe about what trading infrastructure should be: fast, fair, private, and provable.
The code speaks louder than the pitch deck. And the testnet data speaks loudest of all.