The Orderbook Protocol

The Orderbook Protocol Flow

  1. A market maker or searcher makes a limit order at a given price, signing a message that details the terms of the limit order: the assets that they’re offering, the assets that they’re set to receive.
  2. A taker can then attempt to take the order by signing a mirrored limit order of the maker’s original order.
  3. This signature from the taker is propagated back to the maker for the market maker to settle on-chain by a call to the Order settlement contract. The market maker will be given both order signatures (the maker and the taker order) plus an additional server signature (more details in section 2.3).
  4. After the set block deadline time N, if the maker doesn’t execute the order, then the taker gets all the signatures to execute - this is for censorship resistance against the maker.
  5. In the case that neither party executes, then the order is removed from the book after N (i.e. T + 2N).

Order Creation and Execution

Makers and Signatures: On Aori, a maker's order is essentially a signature containing order details and an approval for a taker to execute based on those parameters. This design ensures that makers can place and cancel orders without incurring gas fees and without losing custody of their assets until execution.

Taker Execution: When a taker decides to fulfill an order, the order is removed from the orderbook upon receiving the API call, even before on-chain confirmation. A server signature is then generated, allowing the taker a set number of blocks to execute the order. If not executed within this timeframe, the order returns to the orderbook. To prevent potential DDOS attacks, takers have a limit on the number of orders they can take without on-chain confirmation of fulfillment.

Limit Orders as Intents

Many exciting initiatives have brought about new types of intents to consider for consumers. Teams such as Anoma and Flashbots are working on creating generalized languages for intents whilst others have focused on creating new novel DSLs for their ecosystem e.g. ABCI++. In traditional finance, limit orders have been the natural intent that markets have been built upon. Academia, institutional leaders, and many traditional trading engines focus on using the idea of limit orders as their first-class citizen, and thus we port that concept over to trading on-chain.

A number of benefits come from using a static price limit order as opposed to other schemes.

  • The simplicity and sufficient granularity of a limit order make it a concise object to analyze, transmit, and aggregate.
  • Price is a constant and not a variable - this eliminates most attack vectors (because there is zero slippage) that game the underlying execution environment e.g. sandwiching, single block censorship, etc. to misconstrue the price at a disadvantage to the market maker / liquidity provider.
  • Many traditional market making models can be brought over and applied, offering an almost seamless experience for traditional institutions that wish to tap into on-chain liquidity.

Solvers upon Solvers

The term “solver” has been commonly to describe the programs that work on solving specific problems, likely derived from the field of mathematical logic. This terminology is also applied to the “searchers”, “keepers” and “fillers” that ensure the health of many protocols on-chain. Each being specialized in their role, they’re able to utilize domain-specific knowledge for optimizations and smarter context-driven decision-making.

One emerging trope is the reframing of the role of MEV searchers to create positive externalities for the end user involved. Order flow auctions have driven the narrative for users to be paid for their order flow through solvers bidding to backrun and have the exclusive rights to capture any MEV remaining. RFQ-like platforms such as UniswapX, CoWSwap, and Flood pit searchers against each other to route a user’s trade optimally for on-chain liquidity sources.

Given that the technical skill required to write solvers is increasing with time as new protocols and intent schemes emerge, the modularization of solver functionalities needs to quickly catch up, with multiple solvers under different execution contexts working in tandem, each solving their given problem and being paid for their work in a trustless manner.

Where we see UniswapX, CoWSwap, Flood, and many others focus on the user experience of market takers, with our backgrounds, experience, and network, we see ourselves best positioned to manage the relationship with that of MEV searchers, institutional market makers, and boutique high-frequency trading firms and plugging their liquidity into these more user-facing solutions.