DEEP Protocol · DEEP: Decentralized Entrusted Exchange Protocol White Paper V1.0 1 Overview 1.1...

DEEP ProtocolTechnical White Paper V1.0

DeepEx [email protected]

Abstract

The lack of market liquidity has long beenthe biggest challenge faced by crypto-asset ex-changes. Such a struggle is essentially the con-sequence of market fragmentation that haspersistently dominated the industry. This pa-per introduces a cross-exchange liquidity shar-ing protocol that aims to encourage better mar-ket depth and complete orders at optimal trad-ing prices for exchange users by aggregating thedispersed liquidity from various exchanges. In-stead of practicing commercial authorizationscommonly seen with centralized exchanges, itutilizes a broker network and achieves decen-tralized liquidity sharing in a more scalable androbust manner. The protocol enables the re-alization of a state-of-art decentralized trad-ing platform with progressive cross-chain andcross-exchange capabilities.

DEEP: Decentralized Entrusted Exchange Protocol White Paper V1.0

1 Overview

1.1 Background

An important factor affecting trading experience at crypto-asset exchanges is the lack of liquidity. Buyersand sellers spread out and place orders across different exchanges, yet orders are matched and filled onlywhen they exist at the same exchange. This dispersion of liquidity eventually leads to the circumstancewhere a large number of potential orders are left unfilled across the market.

Figure 1: Trading Depth

As shown in the figure above, the liquidity of the trading pair BTC/USDT scatters across the marketwith no exchange dominating the rest. Even if at the same price level, the bid order from Binance cannotbe matched with the ask order from Huobi. Being able to effectively aggregate the dispersed liquidityfrom different exchanges is thus an important matter to be addressed by the industry.

1.2 Trade Delegation

Some trading platforms, under the title of Aggregated Exchanges, try to resolve this issue by utilizingtrade delegation. They set up broker accounts on third-party exchanges and use these accounts to placeentrusted orders at the same price and quantity through exchange APIs when trading requests from usersare received.

However, this delegation model faces the following problems:

• Assets are kept in a centralized reserve account and are at risk of being stolen or misappropriated;

• The aggregated exchange must keep enough reserves with each third-party exchange for the liquiditysharing process to function. Therefore, the number of supported third-party exchanges and theactual trading depth provided to users are both limited by the size of available reserves;

• Reserves of such aggregated exchanges suffers losses if any third-party exchange encounters securityissues;

• Third-party exchanges can block broker accounts at any time, resulting in liquidity sharing failure;

https://deepex.org 1


• The process of integration with third-party exchanges relies on centralized procedures and thereforecannot be opened up to communities.

1.3 Decentralized Trade Delegation

To address these issues, we are going to introduce the decentralized entrusted exchange protocol. Theprotocol has the following features:

• Incorporating on-chain settlement and off-chain delegation to build a decentralized exchange thatbreaks the liquidity barrier between exchanges;

• Lowering security risks by storing user’s assets in a decentralized manner;

• Preventing intentional account blockage by third-party exchanges and maintaining consistent liq-uidity sharing through a distributed network of brokers. Reserves of the aggregated exchange isequivalent to the total reserves of all brokers with no upper limit;

• In cases of asset security incidents, losses are limited to brokers, not users;

• Integration with third-party exchanges opens to the community.

In addition, the multi-broker approach is able to mitigate security risk, increase API throughput limit,and improve order execution probability.

1.4 Challenges in Protocol Design

Since the protocol is an open system, brokers can join and leave at will. Moreover, the reserve of eachbroker may change at any time, adding uncertainty to whether an order could be successfully executed.

We have, therefore, in the design of this protocol, taken into consideration the following factors: howto split and assign an order to different brokers at different exchanges so that the order is filled, on thepremise of ensuring a certain completion rate, at the best trading price; how to manage the assets of usersand brokers; how to design the order data structure; how to efficiently track changes in order state; howto deal with order execution failure; how to ensure that there is no repetitive execution; how to performorder and broker settlement.

These issues will be addressed in details in subsequent sections.

2 Architecture of the ProtocolThe overall architecture of DEEP (Decentralized Entrusted Exchange Protocol) is shown below:



Figure 2: DEEP’s Architecture

DEEP protocol mainly involves the following components:

2.1 Client

Client is an user interface with interactions similar to that of a traditional crypto exchange. Users canmake deposits, place orders or initiate withdrawals in the same manner as operating on conventionalexchanges.

2.2 Cross-Chain Settlement Network

The Cross-Chain Settlement Network works as the blockchain ledger that manages the crypto assets ofusers and brokers, and is responsible for transaction settlement upon order executions or cancellations.

The network, maintained by a group of notary nodes, enables cross-chain transfers of assets throughmulti-signature scheme and smart contracts. It connects a set of public chains, such as Bitcoin, Ethereum,Litecoin, EOS, etc., to support cross-chain asset deposit and withdrawal. In DEEP, users control IOUsthrough private keys. Consensus by the notary nodes must be reached for a transfer of real assetscorresponding to an IOU to occur, and thus assets will not be misappropriated or stolen even with theexistence of a few evil nodes.

2.3 Relay Nodes

Relay Nodes make up an off-chain order dispatching system that splits user orders into a set of childorders, which are then executed by multiple brokers on different third-party exchanges.

Multiple Relay Nodes constitute a Relay Network that is scalable using the sharding technique.



Unlike in 0x or Loopring Protocol, Relay Nodes in DEEP protocol do not perform order matching locally,but share the liquidity with third-party exchanges through the entrusted exchange protocol.

2.4 Cross-Exchange Gateway

The Cross-Exchange Gateway connects to third-party exchanges through APIs, obtains market and orderbook information of different exchanges, and places orders across exchanges via brokers.

Exchange Adapters facilitates different exchanges to work under the same protocol, and allows other com-ponent modules to neglect the differences in exchange interfaces with order placements and cancellations,information gathering, or order status tracking.

The Cross-Exchange Gateway publishes real-time updated messages, such as changes in price and orderstate, to other modules. If the third-party exchange supports WebSocket API, Update Messages will beforwarded directly. If only REST API is supported, the gateway will acquire and compare state snapshotsthrough polling the latest updates, and forward the updated contents.

2.5 Broker Gateway

The Broker Gateway keeps records of the registration information of the brokers, including their APIKeys and API Secrets on third-party exchanges, which are used to sign requests of exchanging APIs whenorders are placed or revoked.

Anyone using a third-party exchange can become a broker and start earning commissions once the ex-change API is acquired.

3 Key Algorithm

3.1 Order Dispatch Model

Suppose a user intends to buy 10 Token A at a price not exceeding $100, a possible order dispatchingscheme could be: exchange Ei, broker Aj , volume of order Vij , (average) execution price Pij , where i=1, 2, · · · ,m, j=1, 2, · · · , n. Herein the following constraints must be met:

• Order volume ∑i,j

Vij = 10

• PricePij ≤ 100

• Reserve balance of brokerPij ∗ Vij ≤ Bi,j

Where Bi,j is the reserve balance of broker Aj at exchange Ei available for purchasing Token A.

• Probability of execution

Prob(limit_orders_being_executed | bid_price = Pij) > p



• Other constrains: Other constrains may include limits on frequency of access to exchange APIs,prohibition on self-trading, etc.

Order dispatching strategy: Upon collecting all schemes that satisfy the above constraints, select theoption that yields the minimal total user cost.

3.2 Probability Estimate

Order book data of Token A at different exchanges are acquired through APIs. However, due to possibledelays in both API communication and the dispatching system, a limit order may not be filled even if thecurrent best offer is no more than $100. Whether or not the probability of successfully executing an orderis accurately estimated therefore becomes a key factor determining whether the dispatching strategy iscapable of buying sufficient Token A as requested by the user.

The center of the problem, when estimating probability, lies in how to accurately quantify the pricefluctuations occurred in a short period of time. Academic studies on price volatility in financial marketsare mainly divided into two approaches:

• Traditional econometricians use probability, stochastic process and other tools to analyze price timeseries. The Black-Scholes option pricing formula is representative of their achievements;

• Econophysicists aim at the micro-mechanism of financial market statistics and build models basedon individual economic behavior and market structure.

Due to the randomness of market fluctuation, it is hard to decide an absolute winner. In order to adapt tomarket changes and arrive at an optimal strategy, we will consider outcomes of both methods and adjustbased on weights of reinforcement learning architecture dynamics when estimating execution probability.

3.2.1 Research Methods in Traditional Economics

It is generally assumed that the mid-market price follows the geometric Brownian motion with a drift,where the drift rate may be zero.

dSt = µStd + σStdBt

St = Soexp(σBt + (µ− σ2

2)t)

Suppose {Vt, t ≥ 0} follows the geometric Brownian motion

Vs = eσ2νs+σWs

Where Ws(0) = x. Let Hz = min{s : Vs = z} be the time when {Vt, t ≥ 0} first hits z, and Hz conformsto the probability distribution as follows:

Px(Hz ∈ dt) = | ln(z/x)|σ√2πt

32

(z

x)νexp(−ν2σ2t

2− ln2(z/x)

2σ2t)dt

Based on the above conclusion, it is possible to estimate the probability that an order can be successfullyfilled within a certain period of time.



3.2.2 Research Methods in Econophysics

As a scientific approach to quantitative economy, econophysics derives ideology from the field of statis-tical and theoretical physics, and studies inherent laws of financial markets and their causes by buildingindividual microeconomic models.

Suppose {Npt , t ≥ 0} indicates the amount of Token A that can be purchased at a price no higher than

p, the time series {Npt , t ≥ 0} can be represented as a Poisson process with intensity λ:

N0 = 0

P (Nt+s −Ns = n) = e−λt (λt)n

n!

Therefore, the probability of a limit order failing to be matched, or the probability of a qualified sellorder being matched with a buy order, is:

P (Nt −N0 = 0) = e−λt

In order to derive the expression of intensity λ, it is necessary to involve three econophysics researchfindings on the statistical rules of transactions in financial market, which translates, in our case, to thestatistical rule of trading Token A on exchange Ei:

• the frequency of market orders, set to Λ

• The probability distribution of the size of market orders. Numerous studies have indicated that thesize of market orders follows a Power Law Distribution:

fQ(x) ∝ x−1−α, α > 0

• The impact of trading volume on price or slippage:

∆p ∝ ln(Q)

∆p = pQ − s

Set delta = P − S as the difference between target price and mid-market price, therefore

λ(δ) = ΛP (∆p > δ) = Aexp(−kδ)

Where A = Λ/α，k = αK。

4 OrderUnlike the traditional Taker-Maker model, the counterparties in the DEEP protocol come from a numberof different third-party exchanges. Therefore, the order should be organized in separable recursive datastructure in order to maintain the complex state changes in the entrusted exchange process.

4.1 Atomic Order

An atomic order is an order that is incapable of being split further. Atomic orders correspond to ordersplaced on third-party exchanges.



4.2 Aggregated Order

An aggregated order can be split into one or two child orders. Splitting an aggregated order can generatenew aggregated orders or atomic orders.

4.3 Order Tree

The order tree has a binary tree structure, and is responsible for maintaining the relationship betweenparent and child orders. Abstract data structure of the order tree is defined as follows:

s t r u c t Order {// order IdSt r ing id ;// root to the l e f t sub−t r e eOrder l e f t ;// root to the r i g h t sub−t r e eOrder r i g h t ;// order s t a t eint s t a t e ;// t rue − atomic order ; f a l s e − aggrega ted orderboolean atomic ;// t rue − buy order ; f a l s e − s e l l orderboolean sideBuy ;// p r i c e to t radedouble p r i c e ;// t rad ing currencySt r ing tradingCurrency ;// quote currencySt r ing quoteCurrency ;// t rad ing amountdouble amount ;// t rad ing amount executeddouble amountExecuted ;// t rad ing va lue by quote currencydouble value ;// t rad ing va lue executed by quote currencydouble valueExecuted ;

}

Order tree structure is shown in the following figure:



buy,BTC, $8324.15, 10.0

10.0

6.0

5.0 1.0

4.0

2.0 2.0

broker1 broker2 broker3 broker4

Exchangea Exchangeb

Figure 3: Order Tree

In the above example, a user places an order to buy 10 BTC at the price of 8324.15 USD/BTC. Theorder gets split into two aggregated orders of 6 BTC and 4 BTC. The former is then split into two atomicorders of 5 BTC and 1 BTC, and the latter to two atomic orders of 2 BTC. The four atomic orderswill ultimately be executed by broker1, broker2, broker3 and broker4 simultaneously on their respectiveExchangea and Exchangeb.

4.4 Order Dispatch

According to the algorithm described above, the process of splitting an aggregated order into one or morechild orders is called order dispatching, and the process is done by the relay nodes.

For example, in the order tree shown in the figure below, an order of 10 BTC is split into three atomicorders executed by broker1, broker2, broker3 at Exchangea, Exchangeb and Exchangec:

buy,BTC, $8324.15, 10.0

10.0

6.0

5.0 1.0

4.0

broker1 broker2

broker3

Exchangea Exchangeb

Exchangec

Figure 4: Order Tree (unexpanded)

If, for some reason, the atomic order of 4 BTC failed to execute on Exchangec, it will revert to anaggregated order for further splitting. In the example, the relay node will split the order into two childatomic orders of 1 BTC and 3 BTC according to the order dispatching algorithm, and send to broker4

and broker5 for execution at Exchanged and Exchangee.



At this point, the lower right node of the order tree is expanded into a new subtree, as shown in thefollowing figure:

buy,BTC, $8324.15, 10.0

10.0

6.0

5.0 1.0

4.0

1.0 3.0

broker1 broker2 broker4 broker5

Exchangea Exchangeb Exchanged Exchangee

Figure 5: Order Tree (fully expanded)

4.5 Order State

4.5.1 Order State Enumeration

Each order in the order tree displays its state status, as shown in the following table:

State DescriptionPending order is placed, yet waiting for executing

Partially Filled part of the order is executedFilled order is fully executed

Cancelling order is cancellingCancelled order is cancelled

Failed order failed

4.5.2 Order State Machine

Transitions between the various states of an order can be represented by the order state machine in thefollowing figure:



Pending

PartiallyFilled

Cancelling

Filled

Failed

Cancelled

Figure 6: Order State Machine

4.5.3 Determination of Parent Order State

Parent order status can be determined based on the state of its two child orders. For example, if thestates of two child orders are Filled and Failed, the status of the parent order shows PartiallyF illed.See Appendix for determination rules.

4.6 Order State Update

Order information is updated by implementing the Postorder Traversal algorithm. In this method, statesof the child orders are updated first, then the state of parent order.

The pseudo-code of the algorithm is as follows:

void updateOrder ( Order root ) {i f ( root == null )

return ;

Order l e f t = l e f t ;Order r i g h t = r i g h t ;

updateOrder ( l e f t ) ;updateOrder ( r i g h t ) ;

i f ( l e f t == null && r i g h t == null )return ;

i f ( l e f t == null ) {root . s t a t e = r i g h t . s t a t e ;root . amountExecuted = r i g h t . amountExecuted ;root . valueExecuted = r i g h t . valueExecuted ;



return ;}i f ( r i g h t == null ) {

root . s t a t e = l e f t . s t a t e ;root . amountExecuted = l e f t . amountExecuted ;root . valueExecuted = l e f t . valueExecuted ;return ;

}

root . s t a t e = getParentState ( l e f t . s ta te , r i g h t . s t a t e ) ;root . amountExecuted = l e f t . amountExecuted + r i g h t . amountExecuted ;root . valueExecuted = l e f t . valueExecuted + r i g h t . valueExecuted ;

}

5 Relay NodeIn the DEEP protocol, relay node functions as the core central hub of the entire system. This section isintended to give detailed explanations on the design of the relay nodes.

5.1 Architecture of Relay Node

A relay node collaborates and interacts with other components of the protocol, such as the Cross-ChainSettlement Network, the Cross-Exchange Gateway and the Broker Gateway, and it can be broken downinto three modules: the Order Book, the Order Dispatching Engine and the Task Pool. The overallarchitecture is shown below:



Figure 7: Relay Architecture

5.2 Key Components of Relay Node

5.2.1 Order Book

The Order Book is responsible for maintaining entrusted exchange orders. Unlike order book in traditionalexchanges, DEEP’s order book is not based on the Taker-Maker model and cannot be used to matchlocal orders. Each order, under the DEEP protocol, needs to be split into several child orders and sent tobrokers to be executed on remote exchanges. Each order in the order book is, therefore, a tree structureconsisting of parent and child orders. When the state of a child order changes, the order tree recalculatesfrom the bottom-up to parent orders, and eventually to the root order.

5.2.2 Order Dispatch Engine

The Order Dispatch Engine is responsible for splitting an order into multiple child orders so that theycan be assigned to brokers for further actions. It keeps records of a series of“contextual”data includingthe latest price, depth and broker’s available balances on remote exchanges. The data is updated in realtime by the Cross-Exchange Gateway.

5.2.3 Task Pool

The Task Pool is responsible for preserving a set of tasks. Each task corresponds to an atomic order thatcan be executed at a remote exchange. Because each task has an independent state, any two tasks aremutually independent.



5.3 Implementations

5.3.1 Communication between Modules

To improve performance, asynchronous communication is employed between modules through using Mes-sage Queue.

5.3.2 Query Service

The figure above contains only core components of the protocol, without mentioning data aggregation andquery services. In practice, we recommend using CQRS (Command Query Responsibility Segregation),where information displayed on the front-end, such as price, depth, and state of orders, is obtainedthrough an independent Query Service.

5.3.3 Idempotency

Idempotency must be considered with the implementation of modules. For example, if an order executiontask is sent twice to remote exchanges, duplicate trading will occur. Broker may still suffer the lossresulting from price fluctuations even if a reverse trading is performed afterwards for correction.

6 Core WorkflowThe following figure is a summary schematic of the DEEP protocol that details the core workflow anddescribes how the components interact with each other.

Figure 8: Core Workflow

Process Mechanisms in Depth:



1. Broker Deposits at Third-Party Exchanges: Broker deposits a sufficient amount of assets asreserves on a third party exchange.

2. API Registration: Broker applies for API Key at a third-party exchange with permission of queryand trade, and registers the API Key and API Secret with DEEP’s Cross-Exchange Gateway.

3. Broker Deposits at DEEP Exchange: Broker deposits a sufficient amount of assets as reserveson the DEEP exchange for real-time settlements with users.

4. User Deposits at DEEP Exchange: As with traditional exchanges, users are required to havesufficient balance in the DEEP exchange account before placing an order.

5. Order Placement: When an order is placed, it is first recorded as the aggregated root order inthe order tree, then sent to the Order Book.

6. Context Update: The system updates real-time context data on market information and orderstatus through Cross-Exchange Gateways.

7. User Balance Lock In: Before an order is executed, the system attempts to lock up the portion ofthe user’s reserved balance that corresponds to the order amount. For example, if the user requeststo sell 1 BTC, the balance of 1 BTC must be locked up before the execution. A lock-up failuredue to insufficient balance terminates the order with any furthur actions.

8. Order Tree Expansion: The system extracts aggregated orders from the Order Book and callsOrder Dispatch Engine to split the order.

9. Order Dispatch: The Dispatch Engine splits an aggregated order into multiple child orders withthe order dispatching algorithm, the Order Tree will then re-construct based on the dispatchedresult.

10. Broker Balance Lock In: The system fetches unsubmitted atomic order tasks from the OrderBook and attempts to lock up broker balance. A failed balance lock-up will result in a failed atomicorder.

11. Task Submission: Atomic orders that are successfully locked up in step 10 will be created asseperate tasks in the Task Pool for entrusted executions.

12. Task Execution: The Task Pool handles task schedules. It calls the Cross-Exchange Gateway toplace remote orders for each pending task, and ensures that each task is only executed once.

13. Task State Update: The Cross-Exchange Gateway monitors the execution of orders at remoteexchanges and updates the state of corresponding tasks in real time.

14. Atomic Order State Update: Once the task state is updated, the Task Pool sends a messageto the Order Book to update the state of corresponding atomic order.

15. Order Tree Update: When the state of an atomic order is updated, the Order Tree appears tobe “dirty”and awaits for systematic bottom-up updates.



7 Appendix

7.1 Parent Order State DeterminationPending Partially Filled Filled Cancelling Cancelled Failed

Pending PendingPartially Filled Partially Filled Partially Filled

Filled Partially Filled Partially Filled FilledCancelling Pending Partially Filled Partially Filled CancellingCancelled Pending Partially Filled Partially Filled Cancelling Cancelled

Failed Pending Partially Filled Partially Filled Cancelling Cancelled Failed


DEEP Protocol · DEEP: Decentralized Entrusted Exchange Protocol White Paper V1.0 1 Overview 1.1...

Documents

Transcript of DEEP Protocol · DEEP: Decentralized Entrusted Exchange Protocol White Paper V1.0 1 Overview 1.1...