Orion Broker Network, VOBs and more: dev perspective

As a liquidity aggregator, Orion Protocol’s foundation of its Delegated Proof of Broker mechanism forms the basis of its functionality. Understanding the role of how VOBs, Orion Bridge, and the Broker system itself interact together as a process remains an area of expertise for Orion’s development team. Using their expert knowledge of building this pioneering technology, the dev team discusses each area and the part it plays in the overall structure of Orion.

Broker System/Network

The Broker Network forms one of Orion Protocol’s Services and allows individual brokers to connect to other protocol services to be able to receive orders, execute trades and communicate information to the protocol, such as the information on available reserves. Brokers do not see the actual order books unless they purposefully do so from the user end of the terminal. Order books on Orion Terminal come from the Aggregator, another service of the Orion Protocol.

The Aggregator

The Aggregator aggregates order books from CEXs with other liquidity sources, such as pools, to determine what liquidity is available and how to execute a particular order that it receives from the Orion Blockchain (an internal terminology).

One of the primary functions of the Aggregator is to combine and analyze all paths for a trade request/order.

Orion Blockchain

The Orion Blockchain is another service which works as a gateway between other protocols’ services and external blockchains. For order execution, blockchain orders made by users need to be “denormalized” as their format is not directly processable by the Aggregator. This is because both decimal formats are different for a blockchain order compared to an order on an exchange (cryptocurrencies support many decimal places). Pair format is the currency address, i.e. a long string of characters in a non-denormalized blockchain order, and not a coin ticker, i.e. “ORN” like in a denormalized order - readable by the Aggregator/users/exchanges. Orion Blockchain essentially reformats blockchain orders and makes them usable by other services. This is just one of its functions.

Order books and Virtual Order Books

An order book is a combination of buy and sell orders existing on a particular exchange. AMMs and DEXs, such as Uniswap and PancakeSwap, do not have order books in the conventional sense. Instead, they are smart contract operated liquidity pools which do not have buy and sell order books. Users cannot create a limit order on Uniswap. Users alternatively swap one token for another, essentially making a market order. Thus, the term “order book” applies to order books available from centralized exchanges. These books are received by the Aggregator through a Websocket in real time from the actual CEXs such as Binance, KuCoin, OKX and others, which are integrated with the protocol. The Aggregator stays heavily active with updates of the books while it receives information regarding liquidity pools from The Liquidity Pools Service, another Orion Protocol Service, and a component.

Virtual Order Books (VOBs), or Virtual Paths, is an abstraction which defines Orion’s proprietary solution of aggregating liquidity from different sources in a conventional format, further enhanced with virtual levels obtained from complex swap routes. Essentially, VOBs are books enhanced with virtual levels from complex swaps first and foremost - these levels may come from different sources. It then becomes available and visible to users and allows seamless use in the protocol.

In order to understand VOBs, when a swap completes with popular tokens, it is feasible and more profitable to execute a swap from token A to token B, though a direct token A/token B pair remains as a “simple swap” action. However, when aggregating liquidity from multiple sources, whether they are all CEXs or DEXs or a combination of both, a more profitable route may arise. Here, instead of swapping token A for token B directly, swapping token A for token C, and then swapping token C for token B refers to a “complex swap”. The only difference between the two is the number of swaps made in between token A and the resulting token B that a user wanted to receive.

Virtual Order Books is essentially a synthesis of conventional order books and complex swap routes, determined and calculated by the Aggregator. They see the combined liquidity, which would otherwise not be directly available. VOBs do not communicate with the Brokers or exchanges, but by the protocol in order to bring users the best possible rates coming from the overall superior ocean of liquidity that the Orion Protocol taps into.

The Aggregator calculates all routes for a swap/trade request. It then considers the most appropriate/profitable route to determine which swaps to execute and which orders to send out.

Atomic swaps and Atomic Bridge

The term atomic swap is used to describe a swap of a token between different chains/networks without an intermediary. One of the applications of the atomic swap is Orion Bridge. I.e. the user sends a token on ETH and receives it on BSC.

Atomic swap/Bridge schematic:



As such, Brokers do not use the bridge directly. It may be engaged, but it processes from the protocol side. In fact, for Brokers connected to the protocol, there is a specific type of order that corresponds to an atomic swap. What brokers do in terms of communication with the protocol is mainly send information on the available reserves, receive orders, then send counter-orders (example below). The protocol handles the rest.

Bearing in mind all the above, the following example covers these categories and provides more information on trade processing and routing. 

1. User Alice signs and sends her blockchain order with the wallet connected to the Orion Terminal (UI side of the protocol).
2. The order communicates with the Orion Blockchain service. It then needs to process this order, validate it based on blockchain data, denormalize it (i.e. make it “readable” to other services and parties, as described above) and pass it on to the Aggregator.
3. The Orion Blockchain Service then passes the denormalized order to the Aggregator. The Aggregator gathers order books from exchanges and swap data from pools and then determines the orders that need to be placed with Brokers to reach the execution of Alice’s initial order. 
4. The Aggregator will first try to settle the order in its entirety with one Broker as it is the most practical and least costly in the vast majority of cases - the “One Exchange” strategy. The Aggregator is thus using order books received from Brokers and information on their reserves confirmed and validated by the Orion Blockchain. However, in the example, the Aggregator could not identify any Broker that could process Alice’s order entirely.
5. The Aggregator decides splitting Alice’s order into two Suborders, SO1 and, SO2 would be the most effective. It will then send SO1 to Broker A and SO2 to Broker B to receive their respective counters. Remember that Orion Protocol is not a CEX; it is an aggregator, therefore, while the Aggregator has order books of exchanges and is aware of their reserves, it does not have control of the actual orders in CEXs’ order books. It then sends its SO1 and SO2 to respective Brokers, and in response, they send counters that correspond to SO1 and SO2 for actual execution. Without brokers sending those counters, Orion Protocol wouldn’t be able to settle the actual order, only calculate the route and send SOs to respective Brokers.
6. After receiving counters, the Aggregator communicates with the Orion Blockchain to settle corresponding orders and exchange information on completion. 
7. Alice’s order settles, and the information on the settlement communicates via the Aggregator.

A big thanks go to our dev team for covering these technical community questions to help educate everyone on the intricacies of Orion’s technology. Be sure to follow our news, social posts, and YouTube channel for more detailed analysis of the Orion Protocol ecosystem: the universal gateway to the crypto market.