An intro to The Popsicle Decentralized Order Book
As promised we are ready to release this article in regards to what we are thinking of building for to the crosschain decentralized orderbook.
Bear in mind that this is only the initial framework that arises merging the discussion with our devs as well as the DEX code we have ready. In the upcoming months, things may change as well as improve.
The issues we are looking to solve here are the following:
- Easier crosschain purchases.
- Crosschain liquidity problem.
Easier Crosschain Purchases:
Users are often in situations where they may be more active on one chain than another. There are times though, where a user wants to get out of this preferred chain, in order to pursue different yield opportunities or investments.
When these situations arise, the user experience becomes extremely difficult and not straightforward. An example can be that they first need to bridge gas fee funds and then bridge funds to purchase the assets on the selected chain DEXs.
Popsicle original vision has always been to bridge this gap between chains, and we believe that with this next product we will drastically improve it!
Crosschain Liquidity Problem:
Projects that have applications on multiple chains have the problem of fragmented liquidity. Unless they own the liquidity, they need to incentivize liquidity on the DEXs of the different chains, which can be very expensive in terms of emissions. Having a single crosschain DEX will help these projects to have deep liquidity regardless of the chain they are in!
Userflow:
Let’s now dive into the userflow we expect our users to have on the Popsicle DEX!
Our aim is to allow everyone to buy the tokens they want, on any chain they want. How will this work though?
At first users “deposit” to the exchange, you can think of this in the same way as you deposit to a centralized exchange, however the difference here being that it is non custodial and you own the address that is used to trade within the exchange.
The user can deposit any asset from any EVM chain to this contract, you can think of it like a smart contract wallet.
Let’s say a user wants to deposit on the Popsicle DEX. He first needs to deposit funds to the DEX, where the keys are held by the user’s original wallet. After this has happened, the user will have a DEX balance and he will be able to go trade.
Say the user has Ethereum on Arbitrum and wants to buy GMX on Avalanche. ETH is ETH, no matter whether its ETH.e on Avalanche, or ETH on Arbitrum, within the orderbook DEX ETH is seen as ETH.
Once the funds are on this DEX, users will be able to place orders in the traditional order book model. Order book exchanges use a whole different technology compared to the traditional DEX AMMs we are all accustomed to. This will bring plenty of new opportunities for liquidity incentivisation, something that will be extremely interesting to explore in the future!
The user then sells ETH for GMX. His balance on the DEX is now updated, and he has GMX rather than ETH.
Now it’s time to withdraw. There’s two situations on the withdrawal side.
On the one hand there are certain amounts of people that deposited GMX from Avalanche, and there’s a certain amount of GMX deposited from Arbitrum. Depending on the amount to withdraw if there is enough on Avalanche, the user simply withdraws from his smart contract wallet account to his native address to then use the GMX.
On the other hand, if there is not enough GMX on the Avalanche side, then the OrderBook DEX will auto bridge for the user. Meaning the user does not have to go through the UX/UI of bridging, but does still have to pay for the fees.
We have been working on setting up this initial framework, and outline userflows and feasibility.
This is the picture that we currently have, things could however of course still change in terms of the protocol design. There are still a few R&D questions that will need to be solved, but the situation looks very promising. As we know more, we ship the code and we start testing, we will keep you guys posted right away!
In regards to JIT and Limone, we are happy to say that JIT is officially being tested as we speak :), Limone is also close to finish being developed.
