Flashbooks: Intention-Based Orderbooks
Intents vs Orderbooks?
Current orderbooks match incoming orderflow against already existing, or commonly referred to as resting liquidity. This means that liquidity often relies on market makers posting Ahead-Of-Time(AOT) orders on the books, making orderbooks inherently incompatible with instantaneous, or Just-In-Time(JIT) forms of liquidity, such as intents.
Intents are often on the other side of the coin, relying on JIT liquidity from solvers and market makers to fulfil user orders. This offers intents a unique advantage — the ability to aggregate liquidity across ecosystems, blockchains and VMs. However, orderbooks too have a unique advantage against mechanisms like auctions, that are commonly used for solver discovery: Price-Time Priority.
So, how can we establish a best of both worlds arrangement such that intents are compatible with orderbooks? Enter Flashbooks.
Flashbooks: Intents & Orderbooks
Flashbooks allows order placement via traditional limit orders, and establishes an orderbook feed with Orchestrators in the Spicenet Execution Network. Orchestrators consume new limit orders, and chart a "liquidity map", a collection of liquidity routes determing how an order should be executed against liquidity on underlying blockchains, so as to produce the best fill. A liquidity map can be thought of as an arrangement of liquidity routes at specific indexes, such that one gets from the "starting point", to the "ending point", in the most optimal fashion.
The liquidity map is propagated to Executors, clusters of solvers and AI agents, that receive pre-determined instructions from Orchestrators to execute an order in a specified fashion. Multiple Executors may be involved in fulfilling a single user order, expanding the quantity of liquidity routes that can be accessed per user order. In such a case, a single, large user order is broken up into smaller, order fragments, with each fragment being executed by an Executor. The last Executor in the sequence would execute the last specified order fragment and return the resulting asset quantity back to the user's Capsule smart wallet on the destination chain.
Flashbooks' unique feature is allowing resting limit orders placed by users to be filled and settled by the Spicenet Execution Network, Just-In-Time. However, another unique feature is finding the best fill for a user order between native, Ahead-Of-Time liquidity vs global, Just-In-Time liquidity. This is done by comparing the solution provided by Orchestrators vs the best resting bid/offer on the Orderbook.
Flashbooks as a Shared Liquidity Layer
Flashbooks act as a unified source of liquidity for applications building on Spicenet. Applications share liquidity with each other, rather than competing for it, ending liquidity fragmentation. Flashbooks makes liquidity hyper capital-efficient. Instead of liquidity serving just one application, it can serve multiple applications at once.
One of the most interesting features of Flashbooks is that it provides Day-1 and on-demand access to liquidity for applications. Builders can bypass the usual shenanigans of bootstrapping liquidity, lending tokens to market makers, running unsustainable liquidity mining programs, and rather directly access deep pools of liquidity for their desired asset pairs and markets, on Day-1, no strings attached.
Thirdly, Flashbooks makes liquidity highly programmable and configurable. Any application or user can list their own market, take a step further and configure it to be either application-specific or global. Application-specific markets are products whose visibility and accessibility is limited to a single application. Global markets can be accessed by any other application on the network. This gives applications control and sovereignty over the underlying infrastructure.
Last updated