FINAL: Optimizing Liquidity Allocation on SushiSwap’s DEX

About Us:

Elijah Fox@eljhfx is a 4th year undergraduate at the University of Michigan studying Computation, Cognition, and Complex Systems.

Max Resnick@MaxResnick1 is a 4th-year undergraduate studying Pure Math and Complex Systems at the University of Michigan, he will be pursuing a masters degree at MIT in Economics next year.

Parsa Shoa@ParsaShoa is finishing up his final semester of an industrial/financial engineering master’s at the University of Michigan. He received a B.S. in Computer Science from Michigan as well.

Introduction:

Based on feedback from the community we’ve revised our snapshot proposal. We added optimization work for the new trident pools (i.e. weight and multitoken optimization) and risk measurement for LPs. We also took into account some comments on the size of the grant and reduced it by approximately 12% and made the payout over time.

Prior Work:

Over the summer we built an optimization algorithm for liquidity allocation on Sushi Swap (https://twitter.com/eljhfx/status/1426389242096328705 9). It decides which liquidity pools should exist and how much liquidity to allocate into each pool. Our initial results eliminated approximately 100,000$ in slippage and gas fees for traders in a 24 hour period (relative to the current allocation method) while maintaining or increasing fees earned by liquidity providers.

Since our initial optimization algorithm we have been working on several models related to optimizing multi token and weighted pools (both being introduced to SUSHI with the Trident updated). All research is shared on twitter (https://twitter.com/eljhfx).

Deliverables and Roadmap

1. Improve the runtime of the liquidity allocation optimization algorithm on constant product pools and scale up the algorithm to consider more tokens and pools (~October 1st - December 1st):
The algorithm currently takes about a day to run on a subset of tokens using 24hrs of transaction data. Hence the need for funding for computing resources. With AWS credits and a better local computer, we should be able to make major headway into improving scalability. We also have some ideas on how to improve runtime complexity with dynamic programming. With the improvements we have in mind, we should be able to scale up the algorithm to run on more tokens with a week’s worth of data in a reasonable amount of time.

2. Design mechanisms for implementing the constant product version findings to tangibly improve SushiSwap by lowering slippage fees (~November 1st - January 1st):
We plan on working with the SUSHI team to design mechanisms for implementing the findings. We will analyze different tradeoffs and risks involved regarding impermanent loss, gas fees and returns for LPs.

3. Writing an analytical report of the constant product version for the SUSHI community (~November 1st - January 1st): We will create a report with the insights and analytics generated from the algorithm to share with everyone. This will review the findings and provide a summary of each result in a way that can be understood by all SUSHI users.

4. Create a multitoken pool algorithm for the Trident update and integrate it with constant product pools (~November 1st - February 1st):
The algorithm currently uses constant product pools. We plan on implementing a hybrid pool version of the algorithm and integrate it with the constant product pool version. This will allow SUSHI to get a better idea of which hybrid pools should be created and how liquidity should be allocated across them.

5. Stochastically modeling and measuring impermanent loss exposure and risk profile for LPs (November 1st - Febuary 1st):
In doing so we will build a SUSHI to assess the risks involved for LPs in changing their positions or establishing new ones. This can further be used to properly price trading fees to compensate for increased risk

6. Create a dashboard with an easy UI for SUSHI to monitor the findings (~January 1st - March 1st)

7. Writing an analytical report of the hybrid pool algorithm for the SUSHI community (~January 1st - March 1st):
We will create a report with the insights and analytics generated from the algorithm to share with everyone. This will review the findings and provide a summary of each result in a way that can be understood by all SUSHI users.

8. Create an optimization algorithm to find the weights for weighted pools Jnuary 1st - April 1st)

9. Integrate weighted pool optimization into the algorithm with other Trident pools ~February 1st - April 30th)

Grant Size and Use:

The grant would be for $175k USD of $SUSHI paid out over the course of 7 months ($25k each month). The majority of these costs are going to bring on more research engineers as well as support computing costs and the interface for analytics. Up to this, our point research has been

  • Labor: Both of us are currently in school so our additional available hours are limited. To supplement the hours that we will put into this, we plan to bring on a couple of talented employees with similar backgrounds to help speed up the process. We have already hired a master’s in financial engineering to help optimize our models and build mechanisms for measuring impermanent loss.
  • Computing Costs: Building, training, and running Combinatorial optimization algorithms are expensive, both in terms of time and computational resources. The first iteration of our algorithm ran on a MacBook; however, as we scale up the size of the inputs, we will need far more computing power. We plan to use some of the grant funding to pay for cloud computing units and local computing resources.
4 Likes
  • Send this proposal to Snapshot
  • ngmi

0 voters

1 Like