Flashbooks: Hybrid Intent-AMM Orderbooks
Last updated
Last updated
Flashbooks is Spicenet's Hybrid Intent-AMM Orderbook mechanism built on the global orderbook module, Dexterity. Flashbooks blend Spicenet's unique liquidity solution, composing of Network-Owned Liquidity and Solvers, with the global orderbook module, Dexterity, to create deep liquidity across markets. This document aims to explain and simplify how Flashbooks work, and the unique edge Spicenet gains by employing it.
Flashbooks are orderbook primitives providing deep liquidity to traders and applications on Spicenet, by blending external liquidity sources, and protocol-native liquidity(aka Network-Owned Liquidity) into one single, composable, capital-efficient orderbook. We believe that intention-based actions will be the future, and current orderbook primitives will just die out. Spicenet aims to fast forward to that vision with Flashbooks.
On Spicenet, every order is an implicit "intent". Every limit order is an intent, every swap is an intent, every market order is an intent, and so on. How does this matter? This matters because solvers on Spicenet can now create and fill user orders on Flashbooks backed by routes to external liquidity sources. In other words, solvers on Spicenet can stream quotes to Flashbooks from external liquidity sources, aggregated and connecting cross-chain liquidity.
Solvers on Spicenet are also equipped with a unique tool -- Atomic PvP settlement across multiple chains. What does this mean? Isolated market participants, such as a market maker, or an application, or even a rollup can demand liquidity from Spicenet Flashbooks off-chain, and solvers can execute this request on Spicenet, and settle this order on an external chain against the market participant atomically. This was previously not possible before as solvers did not have access to selective orderflow. However, with Atomic PvP settlement, solvers can create orders on Flashbooks backed by isolated liquidity on external chains, and then settle against that liquidity atomically.
Third, solvers facilitate atomic cross-book trades and liquidity. What does this mean? Let's take an example to understand this better. For someone wanting to buy ETH with BTC on an orderbook, it is much attractive for them to sell the BTC for USDC, and then use this USDC to buy ETH. This is due to the fact that BTC/USDC and ETH/USDC have deep liquidity and better fills than exotic ETH/BTC markets. However, this means we are severely limited by the amount of markets and use-cases we can create. Imagine not being able to swap BTC for ETH bro. Seriously? Atomic cross-book liquidity solves this problem for users. Once the order(intent) is placed, solvers immediately find the optimal route to fill this order, such that the user gets the most optimal fill. In this case, the solver would atomically swap BTC for USDC, and then USDC for ETH. But, but, atomic cross-book liquidity is more than just optimal order routing. A ETH/BTC market would actually show combined liquidity from it's outright markets, i.e ETH/USDC and BTC/USDC, on it's orderbooks. So, when someone is taking a tick on a ETH/BTC market, they are actually placing an atomic order on the two outright markets. Wow!
Network-Owned Liquidity is Spicenet's answer to the exorbitant tokens demanded by market makers, and lack of opportunity and access to retail. The aim of Spicenet's Network-Owned Liquidity is to deploy Uniswap-V3 style concentrated liquidity curves on an orderbook, delivering increased returns to LPs and reduced LVR. Traders get attractive fills as liquidity is surrounding the mid-price. And NoL leverages the capital-efficiency of the orderbook to turnover inventory faster, leading to increased fees for LPs.
So, how does Network-Owned Liquidity work? We cover this in depth here, but we describe NoL briefly in this section. Users and LPs deposit their capital into different strategy vaults that fit their risk profile and appetite. Each strategy vault operates over it's own distinct domain(such as spot, futures, cross-book liquidity, etc), albeit adopting a similar liquidity strategy, i.e quoting concentrated liquidity curves on orderbooks. 25% of all fees made at the network level are diverted as fees to NoL LPs.
Liquidity Providers get a receipt token(for eg: $STRATEGY_NAME-TOKEN_NAME). This receipt token can then be staked, making LPs eligible to receive $oPEP. LPs can now either execute the $oPEP to receive PEP at a meagre discount and sell it, or receive PEP and stake it. This is where the flywheel comes in. Staking PEP increases the stakeweight of the user. Applications implementing the oPEP module can incentivize specific actions with oPEP. Existing NoL depositors are incentivized to complete these actions as they can leverage their stakeweight to get higher oPEP rewards. This is a simple yet effective flywheel. Existing application users are incentivized to deposit into NoL to get oPEP, stake PEP, increase their stakeweight, and as a result, obtain higher oPEP when using applications. On the other hand, existing NoL depositors are incentivized to use applications as they get boosted oPEP rewards due to their stakeweight. Applications get increased volume and liquidity by incentivizing specific actions with oPEP. The network also benefits by building a thick liquidity base with NoL.
But what if users end up selling PEP instead of staking it, and end up breaking the flywheel? As a result of myopics, a lot of depositors will want to receive PEP and stake it, instead of selling it. Because, when they sell PEP, they are only getting a one-time, meagre premium(of 15%). However, if they choose to stake it, they get compounded, and a continuous stream of rewards, which are
Staking rewards of PEP(given out in USDC, and other collateral tokens)
Increased oPEP rewards due to stakeweight
Increased NoL yield due to stakeweight
