Skip to main content

Order Matching

Order Intake

User orders submitted via the UI are socialized across the Angstrom network and each Angstrom node will compute solutions for each token pool

Arbitrage impact on Order Matching

Remember that Angstrom auctions off a single arbitrage swap to be executed on each pool. This swap is executed before any order matching begins, meaning that at the time of order matching the underlying pool is considered to be at the post-arbitrage price. Any time there is a change in the outcome of the arbitrage auction, the order matching process will be repeated using the pool state resulting from the current "best" arbitrage swap.

Bisecting Matcher

Angstrom uses a bisecting liquidity matcher that finds the ideal price at which supply and demand are balanced. Starting with a midpoint price based on the current user orders, the matching algorithm will test the target price and sum the following parameters:

  • Liquidity provided/consumed by user orders that would be filled at the given price
  • Liquidity provided/consumed by the underlying AMM pool at the given price
  • Liquidity that can be adjusted by partial fills of Partial-type user orders

An illustration of this process is below:

Order Balancing

User bids will always make liquidity available at a specific price, and therefore appear as solid horizontal lines. When we run out of user liquidity at a price, we move to the next price closer to the UCP. That price motion will appear as vertical dashed lines. Note that once we cross the current price of the underlying AMM, we start to see that those dashed lines become curved. The underlying AMM will contribute liquidity as its price moves from its initial price closer to the UCP, which we can represent via the curve in our path between prices. Finally, when we get to the UCP, we adjust the liquidity via our Partial-type orders as illustrated through the labeled extension - in this example we've shrank our Partial orders to ensure we can balance our supply and demand.

If it is possible to achieve balance (a total of 0 - all liquidity provided is also consumed), the price being tested is considered the "winning" price and is reported as the Uniform Clearing Price (UCP) for this pool. If it is not possible to balance the liquidity at this price, the algorithm will move forward to test the next available target price using techniques similar to a binary search. If the minimum net liquidity at the current target price is positive (too much supply), a lower price is required and the next target price will be the midpoint of the available price range below the current target price. On the other hand, if the minimum net liquidity at the current price is negative (too much demand) a higher price is required and the next target price will be the midpoint of the available price range above the current target price.

This process continues until the algorithm has either found a target price with balanced liquidity or, if no valid target price can be determined, the order book is classified as unsolvable.

Order Killing

If the algorithm has gotten to the end of its binary price search but still finds there to be a liquidity imbalance, Angstrom will "kill" the largest Exact user order available at the final price tested and restart the search with the revised order book. This protects the Angstrom book from anomalous or extreme orders that would otherwise make matches impossible. Note that only Exact orders run the risk of being killed - Partial orders might be adjusted in volume but will not be killed during the matching process.

Uniform Clearing Price

The price found at which supply and demand can be equalized is considered to be the Uniform Clearing Price (UCP) and Angstrom will execute all orders in the pool that are valid at the UCP (i.e. orders for which the UCP is the requested price or more advantageous than the requested price) using the UCP as the final rate of exchange.

AMM liquidity and rewards

Note that given the nature of Uniswap-style AMM transactions, the underlying AMM liquidity pool used to facilitate the batch also undergoes a transaction leaving its final price at the UCP. As is typical of AMM transactions, net resultant price of this swap is substantially less beneficial than the final target price (the UCP). Angstrom will capture the excess swap and return it to the liquidity providers impacted, allowing them to transact at the most beneficial price during this transaction.