The case: Poolshark
The case: Poolshark
Liquidity for all sharks in the pool.
As is commonly known, liquidity is the lifeblood of DeFi. We currently suffer from segregated liquidity, meaning that every protocol has its own liquidity pool and is just limited to that liquidity pool. Over time we’ve seen improvements, - think about protocols like Uni V3 that allows for concentrated liquidity or Rage Trade, which offers deep ETH-USDC liquidity.
Built on Fuel Network, the blazing fast execution layer, Poolshark aims to be a liquidity layer for all DeFi-related activities. The project aims to facilitate token exchanges and introduce novel concepts which introduces granular control mechanisms for liquidity providers. Let’s take a quick look into what Fuel Network actually is and how it differs from the current solutions. Note that this is a TL;DR and is only meant to give a brief overview of this modular execution layer.
Fuel Network
The Fuel Network has a neat feature that it can be built on top of multiple L1’s as a L2 (which is the case right now) or even as a standalone L1. In its current form Fuel Network will be built as a rollup on top of Ethereum, more specifically, an optimistic rollup.
However, this is not another optimistic rollup like Arbitrum, Optimism or an Optimism fork like Metis. Fuel Network leverages the FuelVM and allows developers to create smart contracts in its Rust-based programming language dubbed ‘Sway’. Another aspect in which Fuel Network distinguishes itself from the competition is that it’s utilizing the UTXO model whereas the competitors are actively utilizing the account-based model. A positive side effect of this model is that a user doesn’t manually has to approve and revoke access when interacting with smart contracts. Another major USP is that the FuelVM is unique due to the possibility that allows for parallel transaction execution which subsequently results in a higher transaction throughput. If you’d like to experience how blazingly fast it is, check out the demo of the Sway Swap AMM here, however it must be said that it currently is in the testnet phase.
Other cool things include but are definitely not limited to:
Native account abstraction + predicates
Tokenization of blockspace
The possibility to accept a myriad of non-ETH tokens as gas payment
So, now you should have a brief overview on what Fuel Network is and its unique capabilities. Keep in mind that there is way more about this unique optimistic rollup than I’m explaining here right now, but let’s dive into Poolshark itself.
Current on-chain trading solutions
Generally speaking, on-chain trading currently is available in two generalized forms. The Automated Market Maker (AMM), is currently the most widely on-chain method used for swapping assets and the second form is the Central Limit Order Book (CLOB). The AMM model was initially piloted by projects such as Bancor and Uniswap Of these two trading variants, the AMM is currently the dominating in an on-chain environment. The AMM has multiple variants of which the most prominent are:
Constant Product Market Maker (e.g. Uniswap)
Constant Mean Market Maker (e.g. Balancer)
Stableswap Invariant (e.g. Curve Finance)
Of these products, Uniswap is the most utilized with its well known X * Y = K formula. In terms of liquidity it’s pretty effective since it allows you to practically always buy tokens. However, with thin liquidity it may become unwise because you’ll be paying a high price since it’s programmed to always give you tokens (even though it will be a fraction of the price that it’s currently worth in a liquid market).
In order to provide liquidity in such a pool, a user needs to provide 50/50 liquidity on Uniswap. Let’s say 50% ETH and 50% USDC. But as the price converges to the upside (or the downside), the liquidity providers (LPs) in such a pool will suffer from impermanent loss (IL).
The second variant is the Central Limit Order Book (CLOB) which is being used by centralized exchanges and allows both buyers and sellers to place orders at pre-determined prices. This enables for a better trading experience, with no slippage and no impermanent loss but has the drawdown that it needs a lot of capital. If this CLOB variant will be put on-chain, it can become inefficient in terms of gas usage as was demonstrated by Maker OTC which experimented with the first on-chain orderbook.
Challenges of an on-chain orderbook
The biggest challenge of an on-chain orderbook is liquidity fragmentation, not to be confused with the liquidity fragmentation problem that other projects such as L1s suffer from. Poolshark defines the challenge as follows:
Y liquidity cannot be guaranteed for X gas spent.
This simply means that it’s more expensive for a buyer to execute his transaction than a liquidity provider will be earning from fees due to the high amount of gas fees that is required and therefore will result in a net negative. This can take on extreme forms, especially if there is no minimal fixed order size, since it will be easy to spam a CLOB with many small orders and therefore make it unprofitable for the execution of taker orders.
In the above case this would mean that if a single users wants to buy 100 ETH, said user would need to do 20 separate transactions (14 + 2 + 4 ). This is evidently inefficient, even if it the protocol would be built on top of the blazing fast execution layer known as Fuel. Keep in mind that this example scenario is quite optimistic and doesn’t resemble the reality since it probably will consist of even more smaller amount of funds and therefore will lead to even more transactions. To solve this challenge, Poolshark came up with their solution which goes by the name of the ‘Oceanbook’.
Oceanbook
Rivers and creeks eventually lead to the ocean, as well as the liquidity in DeFi, and eventually will find its way to the oceanbook. The oceanbook is a combination of both the CLOB as well as AMMs with neat unique features such as ‘Directional Liquidity’ and ‘Fungible Queues’. The oceanbook is actually a ‘Queued Market Maker’ and distinguishes itself through the fact that it has both a buy and a sell side. The oceanbook consists out of a the following components:
Book contracts; This contains both automated and queued market maker orders for the involved assets.
Every ‘Book’ consists out of ‘Pages’; These pages are numerically sorted from the lowest to the highest price.
Orders; Every order is mapped to a page
Let’s take the example of a taker order. The book will start to check the pages for their orders and will match the orders which are closest to the specified price. If the order is too large for the current page, the next page will be addressed (with its orders). Obviously, the users that are providing liquidity (in the form of maker orders) have their orders being filled and are receiving maker fees.
Fungible Queue
The fungible queue is similar to having your order/LP positions set at a pre-defined price. The fungible queue will be used to communicate with market markers when their orders are filled and contains some components to keep track of state changes including:
Price; The exchange rate between makers and takers
Volume counter; Track which orders have been filled,
Next page; Next lowest-priced page
Previous page; Previous lower-priced page
Cancel list; Keep track of who cancelled
The fungible queue can consist of both ‘SinglePage Order’ as well as ‘MultiPage Order’. By utilizing the latter variant, an order will be filled by aggregating liquidity from multiple positions on the Oceanbook. The tradeoff here though is that the price might deviate a few ticks. But nevertheless by retrieving liquidity from multiple pages, slippage will be reduced which in turn will lead to an enhanced trading experience.
Directional liquidity
As mentioned earlier, AMMs like Uniswap require a 50/50 liquidity provision but Poolshark is unique in this regard since it allows for single sided liquidity provision. This prevents IL while at the same time generating more trading fees that are paid in the token that’s being used for liquidity provision. The fees that can be earned for liquidity provisioning can be chosen as desired by the LP in one of the following tiers:
1 basis points
5 basis points
10 basis points
100 basis points
Tokenomics
As of the time of writing, the tokenomics are being designed however this isn’t finalized as of right now. There will be some form of value capture for Poolshark’s native token but the exact details are being worked out. It might be good to (actively) use the protocol, anon. I’m just saying …
Roadmap
There isn’t a formalized roadmap yet, but the project is currently in the early stage of finalizing the smart contracts so they can be audited. Afterwards, their V1 is expected to go live on a yet to be announced date in Q1 2023. Post-launch the protocol the team will be enhancing the protocol and adding new features overtime.
Thanks to Alphak3y, for providing feedback on this article and sharing valuable insights.
Disclaimer: Nothing in this article is financial advise and solely serves educational purposes. As of the time of writing, the author isn’t in possession of Poolshark tokens however this might change in the future.