Kuru: Building a Next-Generation DEX on a Next-Generation Blockchain

Chinese

In the crypto world, the decentralized exchange (DEX) is a beautiful ideal: it allows anyone to custody and trade their own assets securely, without permission and without trusting a third party. But on the road to realizing that ideal, the space has long faced a painful trade-off.

Option 1: Automated market makers (AMMs), such as Uniswap

This is like a fully automatic currency exchange machine. You put token A in, and it spits token B out according to a fixed mathematical formula, such as \(x \cdot y = k\). The advantages are simplicity, convenience, and always-available liquidity. But the drawbacks are obvious as well: once trade size grows, price deviation (slippage) becomes unacceptable; and for the market makers who supply capital, capital efficiency is extremely low while they constantly bear impermanent loss.

Option 2: Order books, similar to stock exchanges

We know this system well: buyers post bids, sellers post asks, and the system matches them. Its capital efficiency is extremely high, and the trading experience is usually the best. But the problem is that its performance requirements are absurdly high. On a congested “single-lane road” like Ethereum, every order placement and cancellation has to wait in line, with high fees on top. Running a smooth order-book exchange there is not realistically feasible.

For years, DEXs have swung between these two paths. Users either put up with AMM inefficiency or turn to centralized exchanges (CEXs) for a better experience.

Kuru’s answer: a hybrid model that merges the two

Since each model has strengths and weaknesses and neither can satisfy every need alone, one natural idea emerges: combine them. That is exactly Kuru’s solution: an AMM-CLOB hybrid model. The core idea is to let the two mechanisms coexist and work together inside a single exchange. On one side, it retains an AMM as a base liquidity layer, ensuring that there is always a fallback quote and solving the problem of liquidity droughts or overly wide spreads in an order book. On the other side, it builds a high-performance order book on top of that foundation, allowing professional market makers and ordinary users to submit more precise and more competitive quotes. The result is a unified trading interface for users, backed by two different liquidity sources, with the potential to deliver both AMM convenience and order-book efficiency.

Core Algorithm

Kuru’s central innovation is that it fuses the AMM and order-book models in an unusually clever way. We can understand it through a classic idea from elementary calculus: using infinitely many tiny straight segments to approximate a smooth curve.

Imagine the following:

1. A smooth curve: The AMM formula \(x \cdot y = k\) is a smooth curve on a graph. That curve represents liquidity available at every possible price.
2. Slicing it into tiny “steps”: Kuru’s algorithm walks along that curve and slices it into a tiny segment at every very small price interval, or tick. Each segment can be approximated as a little “step” with nearly constant height.
3. Each “step” becomes an order: Every such tiny step corresponds to a specific limit order at a fixed price, which is then placed onto the order book. The height of the step is the depth available at that price.

In this way, Kuru differentiates the AMM’s continuous, abstract liquidity curve into a series of discrete, concrete, matchable limit orders.

The beauty of this design is that the system gains two forms at once. For ordinary users who just come to trade, liquidity still feels as continuous and ever-present as an AMM. For professional traders looking at the interface, what they see is a traditional order book with strong depth and tight spreads.

Engineering Implementation

The idea of “turning a curve into steps” is elegant in theory, but implementing it on-chain runs into major engineering challenges.

Kuru’s mechanism has one key property: touch one point and the entire system moves. When a trade arrives, even if it only consumes a few price levels, the fair market price changes. To keep the system mathematically correct, the Kuru protocol must instantly do one thing: based on the new price, it must recalculate and update the positions and depths of all remaining steps on the order book.

If that cascading update process were to happen on a “single-lane road” like Ethereum, it would be a disaster:

• Astronomical fees: A single trade could trigger state updates for thousands of steps. On Ethereum, every one of those updates would require its own gas payment. That would make the cost of any trade absurdly high.
• Long waits and severe risk: The system would need to process those thousands of updates one by one, which would be painfully slow. During that period, Kuru’s order book would sit in an inconsistent intermediate state, creating the perfect attack surface for frontrunning bots (MEV). They could predict the protocol’s next move with precision and arbitrage against it, with the eventual losses borne by liquidity providers.

That is the fundamental reason Kuru’s fate is so tightly bound to Monad.

Monad’s parallel execution architecture was built for exactly this kind of problem. When Kuru submits thousands of state-update requests, Monad can recognize that there is no conflict among them, activate its “multi-lane” capacity, and process all of them simultaneously, completing the entire update atomically within a single transaction.

This means:

1. Costs are compressed to the limit: What would otherwise be the cost of thousands of separate operations becomes the cost of a single batched operation.
2. Security is protected: The attack window shrinks from seconds to milliseconds, making traditional frontrunning strategies economically unattractive.

It is fair to say that Monad is a necessary precondition for Kuru to launch and operate. Without this kind of parallel processing capability, Kuru’s entire model would remain a paper design.

Parameter Governance

Even if the algorithm is clever and the underlying chain is fast enough, Kuru’s success ultimately comes down to a very basic commercial question: can it allow participants to keep making money?

That leads into “parameter governance,” meaning how the economic rules of the game are set. It is like running a shopping mall: it is not enough to design a beautiful building (the algorithm) in a location with great traffic access (the system). You also need to know how to price retail space and attract tenants (governance) if you want the mall to remain profitable.

Kuru faces similarly delicate trade-offs:

• Step density (tick density): The denser the steps, the more concentrated the liquidity and the better the trading experience, but the more data the system must record and update, increasing maintenance costs. The reverse is also true.
• Trading fees: This is the core revenue for liquidity providers. If fees are set too high, traders will leave. If they are too low, no one will want to supply capital and absorb risk.
• Risk-management rules: When the market becomes highly volatile, the fairness and effectiveness of the rules used to protect liquidity providers determine whether capital is willing to stay for the long run.

Setting these parameters is a dynamic game that must keep adjusting to changing market conditions. It tests the wisdom of the Kuru team and community, and it ultimately determines whether this carefully designed system becomes a capital-rich financial center or an empty venue undone by poor rules.

Conclusion: A Base-Layer Experiment Worth Watching

Overall, Kuru’s exploration is about much more than just another DEX project. It is closer to a model room, showing what kind of potential can emerge when a carefully engineered financial application meets a high-performance base-layer blockchain.

Whether this experiment succeeds depends on three key questions:

1. At the algorithmic level: Is the idea of “differentiated” liquidity robust enough under real financial-market shocks?
2. At the systems level: Can Monad’s parallel processing capability deliver on its theoretical promise after mainnet deployment?
3. At the economic level: Can Kuru’s governance system find a sustainable balance among all stakeholders’ interests?