UniswapV3 Liquidity Rebalancer

This project aims to give users an automated solution to generate high fees income from UniswapV3 “concentrated liquidity” opportunity

Project consists of a smart contract on Solidity and a simple backend on TypeScript.

Ideally, we should have a frontend interface, but I didn’t have enough time to develop it.

For users I built features like: Deposit funds Withdrawing funds and earned fees Decide if they want to participate in the next staking

Smart contract keeps all the funds, guarantees safety for the users and provides means for the owner (backend) to change liquidity positions. The main work has been done here.

As for the backend, it sets price ranges and executes maintenance transactions.

Users and backend don’t have any connection. Their interactions are orchestrated by smart contract.

What about rebalancing strategy?

Actually, I started with some strategy design in my mind and explained it here, but it turned out that the strategy was flawed, so I have abandoned it and keep writing more basic features to be able to add sophisticated strategies in future after the Hackathon.

This project is built using the most common tech stack for Dapp development:

TypeScript

Solidity

etherjs

hardhat

Ethereum node

uniswap-sdk

mocha

chai

Smart Contract consists of one Factory and a bunch of created Rebalancers. Each Rebalancer represents one existing UniswapV3 pool.

In the Factory contract I keep all global settings, such as: owner, summarizing frequency and serviceFee. They all can be changed.

As for the Rebalancer contract, it operates in two distinguished modes: Stake Managing and Summarizing Results. Most of the time it works in the first mode.

In the Stake Managing phase we have some Stake. Each user participating in that has their own share in total amount. The owner manages positions through price range rebalancing mechanisms.

In the meantime users can withdraw funds from their respective states. All newly deposited funds fall into each user's state. Stake is static and never changes in this stage.

In the Summarizing stage:

We close all the positions

Distribute into each users state the Stake + fees proportional to users share

Create new Stake from the users, who want to participate in the next Stake.

If users are not a lot enough, Summarizing is executed in two separate transactions. Then it falls into the Stake Managing stage.

The Summarizing process can be started by anyone with some frequency (no more than 48 hours). It guarantees that users' funds will not be stuck in the Stake Managing phase, if the owner's account becomes compromised.

The backend architecture is quite simple and straightforward.

We wait for the new Ethereum block to arrive. Then execute the Summarizing stage if it can be started.

After that check if the price is in the open position range. If yes, return to the first phase. If not, calculate the new price ranges using some strategy.

Send transaction to rebalance position accordingly.

Then go back to the first phase.