Poolshark V1: Price-Time Priority for Ethereum
Today, we are excited to announce that we have fully committed to building Poolshark v1 on Fuel Network, the Fastest Modular Execution Layer.
Poolshark v1 will act as a liquidity layer for DeFi that takes place on Fuel Network, facilitating token exchange and allowing a greater level of control and automation for the Liquidity Provider to take advantage of.
Poolshark v1 will introduce two new concepts never seen before on any decentralized exchange: Directional Liquidity and Fungible Queues. Skip to the end of the article if you’d like to learn more about these concepts or follow our documentation updates at docs.poolsharks.io.
Why Fuel Network?
The reasoning behind this is clear: become the largest decentralized exchange built on the fastest and most secure L2 that exists today in the Ethereum ecosystem.
With the introduction of the FuelVM and its native language Sway, our team is able to optimize the UX behind the Poolshark Protocol like never before.
Fuel Network features:
- Parallel transaction processing
- Zero token approvals
- Pay gas fees in any supported token
- Trust-minimized bridging
- Storage space flexibility
Parallel Transaction Processing
FuelVM learns from the EVM, Solana, WASM, Bitcoin, and Cosmos.
Ethereum processes transactions sequentially (i.e. one after the other). When the EVM first came out, 1 or 2 threads was the norm, meaning to achieve maximum decentralization the entire VM had to be designed with this in mind.
With modern processors becoming increasingly multi-threaded, being able to execute transactions in parallel (i.e. multiple transactions at once) is a highly desirable property, especially for Layer 2 solutions.
EIP-648 proposed to add access lists to transactions, i.e. an access list of shared state that would be touched by each transaction.
With such a list, clients can break up transactions into sets and execute transactions across each set in parallel as shown in the picture below.
Access lists in the Fuel are implemented with UTXOs. UTXOs give other nice properties, but for the purposes of parallel transaction execution serve simply as strict access lists.
Each transaction must specify which contracts the transaction may interact with; if a transaction attempts to access a contract not in this list then execution will revert.
Zero Token Approvals
Users send spendable token balance directly to the contract.
Token approvals are required before swapping on EVM-compatible chains due to the account-based model. Each contract has its own record of account of the balance being held by each user.
Since the user is always having a smart contract do something on its behalf, an approve() function call is required before interacting with any contract handling the user’s ERC-20 balances.
Given Fuel Network uses a UTXO-based model, this is no longer necessary. User send spendable token balance directly to the contract which is managing the token exchange and thus there is no need for a standard ERC-20 approve()call.
Pay Gas Fees in Any Supported Token
In Fuel, any contract can mint its UTXO-based native asset using a set of easy asset opcodes.
Typically paying gas fees in the native network token can be cumbersome, due to the need to maintain balance of said token.
Onboarding users in this way causes a severe headache and often the user needs to interact with a friend or access a faucet to get started using the network.
Read more about support for multiple native assets in the Sway docs.
Trust-Minimized Bridging
Fuel was designed and built specifically to be fraud-provable, which enables support for trust-minimized light clients.
Trust-minimized light clients and shared data availability enables trust minimized bridges to other modular execution layers, something impossible to achieve between L1s and L2s as it stands today.
Any user can validate the state of Fuel Network, which increases the trustlessness of the network and lights the path for Fuel Network to become a future L1 that can stand on its own.
Storage Space Flexibility
Whereas Solidity uses 256-bit storage slots, the Fuel VM supports 64-bit storage slots, meaning there is much more flexibility in terms of storage layout.
By having 64-bit storage slots, storage becomes cheaper simply due to the lack of need to compose to the 256-bit standard that the EVM has set.
This means better storage costs from the ground up for the user, and better scaling as an L2 due to the Fuel VM not having the same limitations as the EVM.
If you’d like to learn more about the other technical features that make the Fuel VM unique, we recommend checking the Fuel Book for a list of differences with the EVM.
Poolshark V1: Price-Time Priority for Ethereum
With the v1 release of Poolshark, Liquidity Providers will have greater control over their Liquidity Strategy, enabling directional trades and a more efficient fee model for market makers.
Directional Liquidity
Directional Liquidity is the concept of having your Range Liquidity Position trade in a singular direction, eliminating the risk of the price moving against you while your Range Order is being filled.
It is similar to the concept of Concentrated Liquidity in that you define an upper and lower bound to have your liquidity trade as an x*y=k curve, except liquidity is not reused once consumed.
For places in the Price Action where there is not a lot of liquidity (e.g. selling ETH into USDC at an extremely high or low price), users can leverage the security of the chain to trade in a single direction.
Another common use case for this is when you are trading something such as an Option Token, for which you know the price will converge to 0 by some data (e.g. the option to buy ETH at a much higher price than it currently is).
In this scenario, you want to leverage all the liquidity available and not allow users swapping against your position to leave you with the Option Token and not the stable asset (i.e. ETH/USDC/etc.).
Fungible Queues
Fungible Queuesprovide a way to have your LP position at an exact price such that you will receive time priority for your liquidity. The benefit of such a model is that Liquidity Providers receive 100% of the fees for the liquidity they provide.
At each Tick or price there exists a Queue such that when liquidity is taken, a counter is increased to dictate whose order was filled.
When LPs go to call claim , the Offset will be checked to see if a user has had their liquidity taken and how much.
In this way, the 1st Liquidity Provider with the best price will receive 100% of the fees for the liquidity they provide each time a swap happens. This protocol design will enable faster replacement of liquidity positions and larger fee capture for liquidity providers that offer the best prices.
Grid Trading
A great use case for both of these Liquidity Strategies is in something like a Grid Bot, where users have sets of Buy and Sell orders as shown in the image below.
Grid Trading are automated programs designed to use the grid trading strategy, which involves buying low and selling high. If the price of a crypto drops below a set limit, sell orders will no longer be executed.
Typically these types of bots are offered on centralized exchanges, and could be a great way to average users to help make the market more efficient by settling around a median price.
Conclusion
With the launch of Poolshark V1 expected Q1 2023, we are excited to announce our build out on Fuel Network as well as our contribution to the world of decentralized exchanges: Efficient Price-Time Priority.
Directional Liquidity as well as Fungible Queues add to the advanced liquidity strategies that already exist within decentralized exchanges, enabling more flexibility and control over how your assets are traded on the exchange.
While we complete our release of v1 over the remainder of the year, we are also cooking up more research to provide better outcomes for both Liquidity Providers and Traders.
Our core ethos is to make this relationship more symbiotic and improve transparency for LPs that are seeking to collect fees.
More of our research as well as the whitepaper to complement Poolshark v1 will be released in the coming weeks, so make sure to follow us on Twitter and join our Discord to engage in discussion with our Community and Team.
You can also follow our Medium to stay up-to-date with the latest Poolshark news and announcements.
