Trading on Aori

Making Orders

To make an order: Connect your wallet and simply select the two tokens you wish to sell and buy, and their respective amounts.

Upon order submission you will be prompted to approve a token spend of the token you're selling and to sign a digital signature for the execution of the trade. After signing you're order will be active and can be taken but the tokens you've placed for sale will remain custodied in your wallet until the time of execution initiated by a taker.

Public & Private Orders

Aori provides makers the option of creating public or private orders, if a maker does not have a desired counterparty, public orders will be displayed on Aori's UI to be taken by any other user. If you're trading with a pre-determined counterparty, select the private trade checkbox and provide the taker with the generated order ID for their submission into the take order form. You can select “public” or “private” to determine if you’d like the order to be take-able by any user or only users you share your order ID with.

orderform

Cancellation

orderform

To cancel an order: Click the cancel button on the order you'd like to cancel in the user orders table. This will not delete the order from our database nullifying any opportunity for a taker to attempt to take the cancelled order.

Taking Orders

To take an order: Select a public order you'd like to take from the active orders table, or input an order key for a private order provided by a maker. Once a valid order is selected, press the take order button to initiate taking the order.

orderform

Filling an order will prompt the taker to approve a spend of the consideration token. Then the user will be promted to approve the taking transaction to the orderprotocol.sol smart contract. Upon transaction success the taker's tokens will be transferred to the maker and the maker's tokens sent to the taker, settling the trade.

orderform

Last Look Orders

A last look order is a limit order in which after the taker elects to fulfill the order, the maker gets the opportunity to accept or reject the order; aka getting one last look. The purpose is to ensure that the maker is not taking on toxic flow at the time of settlement due to a change in the landscape before and after they made the order. This is especially crucial for market makers on Aori given the rapidly changing state of a block based on completely arbitrary features such as who won the block building auction, or the fee structure of the pool they are planning to execute a trade through. So we allow the makers to get the first rights to settle trades on Aori. Don’t worry, there are punishment mechanism we’ll go over later for makers that do not elect to settle a trade in a timely fashion.

Separation of MEV and State

Once a maker receives the notification that a taker has elected to fill their order, they can then route that trade using the taker’s signature and order details created when they made the API call to fill the order on-chain with any arbitrary logic they choose on top. Meaning if the maker is a CEX liquidity provider, they can close the arbitrage on chain with their own capital. Or more importantly, if they’re a searcher they can open a flash loan, fill the order, then execute ANY route they wish to on-chain so far as they repay the flash loan in the same block. This means for the first time searchers will have access to CEX liquidity directly on-chain, that they can use to CAUSE MEV on AMMs. We expect this to make CEX-DEX arbitrage orders of magnitude more competitive and lead to substantially more LVR and adverse selection on-chain for AMM Liquidity providers.

Let’s look at a concrete example of an MEV order execution:

  1. Suppose a searcher / solver would be able to optimally route through on-chain DEXs to achieve a combined rate of 1100 USDC for 1 ETH.
  2. Also suppose that the current Aori orderbook has only limit orders to sell 1 ETH at 1000 USDC. Said Searcher can participate in the orderbook to receive user order flow through us by listing a limit order at 1050 USDC, even if they don’t have the liquidity upfront.
  3. When a user attempts to take the order, the user signs off on the market order to take this trade, which is then propagated to the searcher via API to execute on-chain. It is the searcher (who is the maker in this case) that can either choose to fulfill this order from utilizing on-chain liquidity (flash loaning in the assets JIT and then doing their routing for an atomic arbitrage profit of 50 USDC) or from their own inventory (like a traditional market maker doing statistical arbitrage).
  4. A consequence of this is that searchers (and even DEX aggregators) are naturally incentivized to list Aori orders even if they don’t have the liquidity right now, because it will be available at settlement time. Thus, Aori is at launch as competitive as RFQs and DEX aggregators ( searchers become third-party solvers that price and find optimal routing).

Ensuring Maker Honesty

if a maker does realize that a trade has moved against them and they have decided not to fill the order, the Taker than has the ability to settle the trade on-chain themselves and collect the MEV profits regardless of the profitability of the trade for the Maker. A particularly HILARIOUS scenario we envision could be the following:

  1. A taker fulfills a limit order
  2. A maker lets the block deadline pass, not fulfilling the order
  3. The taker then opens a flash loan, sending the tokens TO the MAKER
  4. Fulfilling the order FOR the maker, using their signature
  5. Capturing the MEV on-chain and repaying the loan, keeping the Maker’s profit

So in both scenarios, with a good or bad maker, MEV is captured against on-chain AMMs and provided as surplus to Aori traders.

Order Locking and Pre-Confirmations

A server signature is given to the executor in step 3 of the orderbook flow for the server to prevent a number of signature replay attack vectors. The server signature is used to sign off on the start and expiry time of the order, the chain id of the order, and the matching of the maker and the taker orders.

  • The start time, expiry time, and chain id of the order are needed for user orders to be resistant against reorgs and signature replay attacks (both on the same chain and cross-chain) that can happen out-of-protocol.
  • The matching of the maker and taker orders is needed to only allow certain matchings to occur based on which taker has locked in the limit order first. This prevents another searcher, builder, or other entity from stealing the order.

By propagating the server signature along with both order signatures to the maker first, we are able to offer a “last look” functionality in which the maker gets first priority to put it on-chain and collect any atomic MEV.

Using the pre-confirmation on the price that the trade is going to be settled at on-chain, either the maker and the taker can work to arbitrage against other DEXs, perhaps on other chains, or against centralized venues (CEXs), or to hedge their position.

The matching of trades occurs in real-time (and therefore, so are the price pre-confirmations), meaning that both parties know the price that is going to be settled on-chain as opposed to the norm of only finding out their execution price after waiting until the end of a block / priority gas auction. This eliminates slippage entirely, significantly improving the ability of both makers and takers to price their execution risk.

Virtual Orders and “Flash Market Making”

“Virtual” limit orders can be made even if the liquidity is not yet available for the market maker - it is only required at settlement time. This enables our order book to work as both a DEX but also a DEX aggregator, in which market makers and searchers do not need to post collateral to make a limit order - they can source assets to fulfill an OTC swap from other DEXs on-chain at execution time.

The propagation of the signatures to the market maker facilitates this, as the maker will need control over execution to either pull the funds from their own custody solution just-in-time (taking on inventory exposure) or they can choose to flash loan the funds and perform an arbitrage with the best optimal routing back on-chain.

As MEV-aware market makers and sophisticated searchers compete, the competitive pricing of limit orders will soon internalize MEV profits to become top of the book and deliver this value back to the user.

A number of trading strategies can utilize this approach of providing liquidity just-in-time from a reserve:

Maker Strategies

  • Delta neutral market making - given gasless order creation and cancellation, market making on Aori is almost analogous to trading on a centralized exchange. When a taker takes your limit order, unwind the position on another venue.
    • Atomic arbitrage - find the best optimal route for e.g ETH → USD and quote a little under the rate from USD → ETH as a limit order. If a taker takes that trade, a profit from the atomic arbitrage can be made by closing the loop. The order-locking mechanism ensures exclusive execution rights for the searcher so pricing competitively is key.
    • Cross-chain arbitrage - after a taker takes your limit, first front the funds from an on-chain reserve / custody solution, locking in a price on one chain that Aori is deployed on, this rate can be arbitraged against another on another DEX on another chain or via locking a rate through Aori on another chain.
    • CEX - DEX arbitrage. Like cross-chain arbitrage, but unwinding the position on a centralized venue like Binance, Coinbase, or Kraken.
  • Scalping - A strategy that seeks to profit by either making the spread or quickly trading for quick profits - one will quote both a bid and an ask price on a market e.g. ETH / USDC, and as takers buy and sell, update prices to minimize inventory exposure.
  • Stoikov Market Making - similar to on-chain full range AMMs, place symmetrical bids and asks limit orders through defining the quantity at each price point. The ability to change the curvature freely with the volatility of the market in a gasless manner.

Taker Strategies

  • CoWSwap solving - first fronting the funds from an on-chain reserve / custody solution and locking in a price as a taker, this rate can then be provided to CoWSwap minus some for profit.
  • UniswapX / 1inch Fusion fulfillment - first fronting the funds from an on-chain reserve / custody solution and locking in a price, the searcher can use the liquidity off Aori’s order book to fill a descending Dutch auction limit order and capture the spread.
  • CEX - DEX arbitrage - like a market maker doing a CEX - DEX arbitrage strategy, but allowing for the market maker to settle the trade.

Flash market making is greatly inspired by an idea of ‘just-in-time gas’ mentioned in @pumatheuma’s talk at Research Day.