The problem LPSwap solves

Vision - Batch multi-step LP processes into a single step.
Problems -

1. Liquidity Provider(LP) tokens are an essential aspect of providing liquidity for DEXs. But the process of creating or liquidating an LP token involves a lot of steps. The user should have two tokens on the wallet — Token_X and Token_Y. In order to become a liquidity provider, he/she creates a pair of possessed tokens and adds to liquidity to an existing pool. After adding liquidity to the pool, the LP token (LP_Token_XY) will be added to the user’s wallet. To summarise, it requires at least 3 steps. What would happen if you wanted to create five LP pairs and offer liquidity for each of them? 15 steps! What a lengthy procedure.

2. The second problem is there is no way to exchange LP tokens from one DEX to another.

Solutions -
Hence, we are trying to simplify these problems so that users can create multiple and exit multiple LP positions in one go.

To do so, we have built three features:

1. Transfer LP tokens from one protocol to another. Example: Transfer an LP pair from Uniswap to Sushiswap.
2. Convert multiple LP pairs and other tokens into a single LP token in one click.
3. Convert multiple LP pairs and tokens into multiple tokens in a single click.

To conclude, we want to solve the problem of multiple steps in regard to LP swapping.

Future Improvements - As of now LPSwap only supports QuickSwap & SushiSwap v2. We are planning to scale this to Uniswap v2/v3, Quick/Sushi Swap v3. Also, due to time constraints, we have not been able to add LP token migration to the frontend dapp, where users can migrate their liquidity from 1 DEX(from uniswap to quicswap, etc) to another in a single click.
Also once the v3 version goes live we will add a v2 to v3 liquidity migrator in a single click/transaction.

Challenges we ran into

Solidity - As the contract takes in a lot of complicated data from different DEXes for LP swaps, so we were stuck in a stack-too-deep error. Because of this, we had to refactor the whole contract so that more parameters can be adjusted and make the contract scalable.
We have created a wrapper over 1inch and quickswap contracts to add multiple swaps feature. Both of these protocols work in different ways so we had to adjust all the functionality in a single contract which involved a lot of deep understanding of the protocols.
Frontend - Initially, we thought of using external APIs like Unmarshal/Covalent to fetch the LP balance for a user and also the lp token pairs for quickswap. But unfortunately, none of them was providing APIs to handle these custom requests for quickswap. So we had to create our own custom list of tokens and LPs which can be scaled as and when required.
It took a lot of time to mould the required tokens, LP tokens and pair data to make it compatible with our architecture.
At last, we have created a small pathfinder which considers the most commonly used bases for the LP tokens for which we have the most liquidity available on the dex.

We have also integrated 1inch APIs for token swaps so that the user gets the best output price possible.

For a smooth transaction, we had to include quickswap/sushiswap v2 SDK so that we can fetch all the LP token details required for the swap. But both of them had their unique contract address, so we had to make it dynamic as the SDK codebase is same except few addresses.

Apart from that, we wanted to deliver the best UI/UX experience to the user so it took a lot of time to develop a design which is easy to understand and that a user would love.

Note: We faced an issue with integrating multiple dex v2 SDK as we were not getting the Trade object because of which the integration with the frontend contract integration is not complete in 36hrs but our contracts are fully production ready for multiple LP tokens.