Limit Le Swap Exchange

Mina Navigator Proposals
1

This topic is to discuss the proposal submitted by @kadirchan
Please see below for the details of the proposal and discussion.

28th November, 2024
Current status: Under Consideration.
Opened for community discussion on: 28th November, 2024.

2 Likes
2

LimitLeSwap DEX

LimitLeSwap
LimitLeSwap633×139 6.83 KB

Project Background

LimitLeSwap is a DEX appchain on Mina that provides less slippage and more efficient swaps compared to Uniswap V2 like AMMs. It achives this by using constant product market maker pools and orderbook swap execution at the same time.
LimitLeSwap built in ETHGlobal 2024 and won best Mina application or library built using Protokit 1st place.

Proposal Overview

LimitLeSwap was created as a hackathon project in a short time with a lot of hard work. It is currently working as a prototype on Protokit, this proposal aims to bring this DEX to live on Mina Devnet.

Problem:

  • DeFi, which is essential for supporting other applications in Web3 ecosystems and one of the most popular areas among users, has yet to make significant breakthroughs in terms of products, despite Mina continuing to gain new users and grow the ecosystem every day.
  • Although the token standard has been released, there is still no platform where users can list and exchange their tokens.
  • Also, there is no platform where users in the ecosystem can invest their assets other than Mina staking.
  • Due to off-chain execution and long block times, building DEX like applications that require low latency and quick response times directly on Mina L1 would negatively impact user experience.

Solution:

  • LimitLeSwap aims to be a user-friendly DEX with a familiar user experience for Web3 users. This approach ensures that both existing Mina users and newcomers to Mina can adapt LimitLeSwap quickly.
  • It allows users to bridge their tokens, create pools and create a token marketplace within Mina.
  • Enabling users to provide liquidity to the pools and earn from the fees accumulated in these pools. This will increase the use of DeFi in Mina and enable users to invest and utilize their assets.
  • By performing these operations in the Protokit appchain and settling them to L1, to increase throughput and minimize the latency experienced by the user as much as possible. Future of Dex is appchains.

Impact:

  • To show that Mina can be a universal settlement layer for custom appchains.
  • Taking a pioneering role in terms of Mina Defi and the use of L2 on Mina, providing inspiration and how-to’s for future Mina DeFi developers.
  • Increase throughtput by computing all transactions offchain and using Mina only as settlement layer.
  • Growing Mina DeFi to create new opportunities and attract new users to the ecosystem.

Audience:

  • All DeFi users in the Mina ecosystem.

Architecture & Design

Detailed Design/Architecture:

LimitLeSwap uses Constant Product Market Maker pools to determine price as
(X*Y=k) like Uniswap V2. This enables users to create liquidity pools for any token pair and trading them.

Token X spent
Token X spent713×568 33.9 KB

This type of market maker algorithm is very useful in terms of providing liquidity across the full range of the price, but it can also be very inefficient in situations where there is limited liquidity because liquidity is distributed across the entire price.

We can give an example of the problems this can cause. Suppose Alice and Bob want to take opposite trades on the same pool without each other’s knowledge. The current state of the pool is 500 USDT against 300 Mina. In this case, Bob, who wants to sell 30 Mina, will receive 45.3 USDT in return for this trade.

Token X spent-2
Token X spent-2713×568 49 KB

Meanwhile, Alice, who needs 25 Mina, wants to exchange her USDT for Mina, but finds that the amount she needs to pay to the pool is 45.5 USDT. As seen, both parties are losing value due to the price impacts in the pool.

Token X spent-3
Token X spent-3713×568 48.7 KB

What if users who want more return could create an orderbook where they could match with each other and use it at the same time?
LimitLeSwap allows users to create order books that are verified on-chain and stored off-chain, and then swap directly with each other to overcome some of the downsides of price impact.

When users want to trade via LimitLeSwap, web client will scan and calculate optimal limit orders if there any order that will provide greater return for the user’s trade. If these limit orders are sufficient to fulfill the user’s needs, they are filled directly and the user executes the trade. If there are not enough limit orders to fill the total swap, these limit orders are filled first and then the missing amount is swapped using the pool.

This method protects users who want to avoid slippage for both buying and selling. So LimitLeSwap try to maximize output by filling part of its trades with limit orders, if available and profitable for the user, and the rest from the pool.

Token X spent-5
Token X spent-51416×848 58.3 KB

image
image1094×1050 49.5 KB

All this process is done in Protokit L2 to increase efficiency and solve concurrency. The bridging of users’ assets between L1 and L2 is achieved through bridge and settle contracts.

Future Visions:

Some of our greatest desires are that the project progresses as we expect:

  • Upgrade LimitLeSwap core for supporting concantrated liquidity to maximize asset efficiency like Uniswap V3.
  • Launch to mainnet after audits of Protokit and LimitLeSwap.
  • Support much larger transaction batches with increased speed of o1js recursive proving.
  • Supporting mobile devices to make trading more reachible.
  • Enabling KYC/AML with collaborating projects within ecosystem to ensure regulatory compliances.

Existing Work :

Budget & Milestones

Deliverables:

Runtime Modules

  • Refactor and improve existing codebase to ensure that the product is ready for release on Devnet.
  • Implementing and performing the tests by covering the entire codebase since detailed tests were not done before.

New Features

  • Enable routing between different pools to enable users to swap more efficiently between assets that does not share common pool.
  • Efficient data fetching between UI and appchain by using new Protokit indexer.
  • Storing historical data and thus providing more comprehensive information to users such as Price Charts, Executed Orders, Trading Volume etc.
  • Add support for Mina Fungible Tokens to enabling users to list their tokens.
  • Transaction fees to cover expenses.
  • The current algorithm only calculates limit orders by sorting them by price, which is not always optimal. A knapsack variation algorithm will be introduced to calculate the limit orders that should be included to maximize the return on trades. Thanks to routing, orders from different pairs can also be included in the same trade.
  • Additional fallback & recovery mechanisims for Protokit: Since it works with a single sequencer, this causes a single point of failure in the appchain. A structure that ensures continuous backup of persistent data (states and mappings) and fast migration in case the host machine has problems.

Bridge and Settlement

  • Enable bridging between Mina L1 and Protokit to allow users to move in and out their funds for trading.
  • Implement settlement contracts and bridge mechanisims.
  • Articles about how to settle and bridge with using Protokit to give insights other Mina developers.

UI/UX Improvements and Refactors

  • Current web app implementation built in hackhathon and codebase needs to be tidied up.
  • Performance improvements of data fetching and calculations on front-end.

Mid-Point milestones:

  • Complete refactoring and improvement of runtime modules.
  • Partially completed implementation of bridging and settling between L1 and L2.
  • Implement basic routing between different pools.
  • Improved version of UI with advanced data features like historical data.

Project Timeline : 3 Months
Budget Requested : 32000 MINA
Budget Breakdown:

  • Renewed and tested runtime modules with new features (10200 Mina)
  • Settlement contracts and bridging with supporting Fungible Tokens (9600 Mina)
  • UI/UX improvements and new feature implementations (9200 Mina)
  • Budget of oursourcing for UI/UX, server costs and other unexpected expenses (3000 Mina)
  • Wallet Address:
    B62qonjCTTzww6w7Msquv5sH5Ti5A2XNPfzjBPzN6zFHkX8LyzKuS4C

Team Info

This section provides details about team.

Risks & Mitigations

  1. Security
  • Project strongly depends on Protokit and there is no precedent project in DeFi that launched on mainnet. Also Protokit still not audited for mainnet and LimitLeSwap also needs audit before launch
    • Protokit is expected to be ready for mainnet in the near future. Once LimitLeSwap is thoroughly tested and audited, it will be an example for other developers and this problem will be eliminated.
  • Only one sequencer running whole appchain and this can cause single point of failure.
    • Develop fallback mechanisms for the sequencer and settlement contract.
  1. Scaling
  • There is a trade-off between block transaction capacity of Protokit and circuit complexity. Because every transaction needs to computed inside sequencer before L1 settlement and this computation takes more time with bigger circuit size.
    • Optimize circuit design to reduce complexity and giving maximum flexibility to users.
3

How will asset transfers be conducted on Mina mainnet here?

1 Like
4

I hope I understood your question correctly, if you mean the transfer of tokens between Mina L1 and Protokit appchain, we can do it through bridge contract, users can deposit and withdraw their tokens to the appchain.