Connecting the Bitshares DEX to existing trading systems

In my last posts here and here, I examined Bitshares as a trading platform. In this post, I will examine some of the challenges in implementing the FIX protocol to connect to the DEX.

The vast majority of crypto/alt currency exchanges have some sort of API to connect to their systems and trade. These systems vary in complexity and robustness. They are usually based on web apis such as websockets and/or REST.

There are also products that provide a front-end to some of these exchanges. These products manage the complexity of connecting to the various exchanges for data feeds and trade management.

As the technology draws interest from institutions, some exchanges have implemented the FIX protocol to their exchange. This allows the institutions to connect their existing OEM (Order entry & management) system to the exchange with less up-front investment in solving the connectivity issues.

The Bitshares DEX is an excellent candidate for such an interface. It would allow the large institutions to connect to the exchange, and trade the variety of assets that are available with less up-front investment in the implementation.

But there are aspects of the DEX that create technical and financial hurdles to the implementation. As I’ve examined the code, I have started a list of these. Below are the biggest I find.

On the technical side, there are two big hurdles:

1. Order Types - Many organizations use complex order types to manage their positions. The DEX has limit orders, but does not go much beyond that. I forsee three ways to handle this problem;
   1. Do nothing, only provide market and limit orders
   2. Modify the code to add these order types to the system
   3. Have the FIX code “mimic” these order types
2. Account/Key management - The FIX API engine would probably sit in front of a wallet, or be part of it. Organizations can have a large number of “sub-accounts”. They would have to manage the key infrastructure for their multiple accounts, or have this API hosted by a trusted third-party, and have them provide a mechanism for on-boarding new accounts.

On the business side, there are also two big hurdles:

1. Monetization - There is the cost of building this piece, and the cost of maintaining it. If the Bitshares Foundation took care of the development, they could control the functionality, and would be responsible for the cost. If a third party builds it, integration will be more difficult.
2. Marketing - I have not done market research on such a product. My knowledge is firmly on the technical side. However, I do know that the FIX protocol, despite its maturity, still has a strong following in the institutional investing space. It may require more research, or it may be “build it and they will come”.

Side note: If developed by a third party, It may be good to consider other exchanges, and design the system as such that it can connect to those other exchanges as well. A more generic front end to the variety of exchanges out there.