The problem kuru dex solves

This product aims to solve the challenges faced by existing on-chain orderbook based perpetual dexs regarding high costs, inefficient market order fulfillment, and unfair treatment of market makers.

1. The expense arises from the on-chain iteration of multiple limit orders, which can exceed the block gas limit and incur high transaction costs.

2. To address this, the solution proposed by Clobber involves breaking down market transactions into two parts. Market orders are placed and fulfilled based on order book depth, while market makers can claim their orders within the claimable range. This approach utilizes segment trees to validate order claims, but segment trees are bulky data structures.

3. Gridex addresses the issue by dividing the order book into grids and allowing market makers to provide liquidity to each grid. They calculate price movement using their Grid Price Linear Movement algorithm. However, maker orders are not filled sequentially based on order placement time, which may be perceived as unfair. Makers receive rewards in the form of "maker fees" for contributing to book depth.

4. This product introduces an algorithm that creates an on-chain limit order book with several key features:

• Limit orders can be placed efficiently in O(1) at pre-existing price points and in O(log(n)) for non-existing price points.
• Orders can be claimed swiftly in O(1), and maker orders are filled sequentially based on the order placement time, ensuring fair treatment.
• Orders can be canceled in O(1) time.
• Market orders can be executed in O(n/s) time, where 'n' is the total market liquidity and 's' is the size of market liquidity at each price point. This approach ensures that substantial gas is required for single-handedly moving the price significantly. Additionally, single market orders typically span a limited number of price points.

Challenges I ran into

During the project, I encountered several challenges within the limited timeframe of the hackathon:

1. Limited availability of Pyth testnet oracles for token price feeds: Many tokens lacked price feed data, making it difficult to obtain accurate and up-to-date pricing information. This required additional effort to identify which tokens were supported and find alternative solutions for tokens without price feeds.

2. Unfamiliarity with subgraphs: As I hadn't worked with subgraphs before, I had to invest time to understand and create the necessary subgraphs for the project. This involved learning the subgraph development process and configuring the data sources and mappings correctly.

3. Frontend development limitations: Unfortunately, my frontend developer friend was unavailable during the hackathon, hindering progress on the frontend implementation. As a result, the frontend remained incomplete, but we plan to complete this and launch on mantle main net soon.

4. Gas optimization complexities: Achieving gas optimization proved to be challenging and time-consuming. Writing efficient smart contracts and optimizing transaction costs required careful consideration of contract design, data storage, and function execution. This optimization process demanded extra effort and attention to detail.