liq.fun

Demo

About

The problem it solves There is a demand for products to be built entirely onchain, and to create games that are as fun as trading. This has lead to the rise of onchain and liquidity based games, such as pump.fun & Crypto: the Game. Users do not want to create another profile, they want to use establised identities and use them. We are making liq.fun fun, simple and easy to get hooked into. Users also want to be able to short against certain meme communities, and long others. Users in the crypto community find that trading is one of the best ways to make money and have fun, we are offering a new alternative to this dynamic.

How it's made

Challenges we ran into ## Creating the liquidation and reward logic During development, we faced an issue with our liquidation logic. First, it was difficult to test off-chain since it relied on Uniswap V2/V3 contracts. We'd been using Base to test since prices were so cheap and we could send low amounts of tokens with actual liquidity in order to practice swapping on-chain. When game completion wouldn't work, we had to figure out how we could easily emulate Uniswap and their contracts in testing. We solved this by using hardhat fork testing, allowing us to solve the issue with game completion, without having to spend money, or do manual contract interactions. We could fork the state of the chain at the current time and run it locally against tests on a localnode with current chain state. ## Writing the GameManager contract Our GameManager contract is proprietary and there wasn't another project we were just able to fork. By working through the Uniswap documentation, testing, and trial and error, we were able to come up with the GameManager that supported V2/V3 Uniswap Pairs and allowed them to battle each other since they would require different logic for swapping the tokens. Perseverance was key in order to figure out how to do this. At some points it seemed like things just weren't working properly but we kept iterating until we got to where we needed to be. ## Creating our backend infrastructure We store information off-chain to serve data quicker to the frontend and not have to constantly rely on a web3 connection to fetch data. In order to keep up with chain state, we created a system of listeners and BullMQ workers that could handle creating and updating information in our database. This bot would crash after 3 hours every time and we had to fix it. We decided to try a new RPC provided with Chainstack and using http transports instead of websockets and the bot has run perfectly for over a week, with 0 crashes! Once again, perseverance is key!