Our exchange platform is built on microservice architecture. This will allow, in the future, to quickly scale the project. Each part of the server side will be engaged in only one logical task and therefore increasing the computing capacity for only one task will allow you to save the budget for maintaining the system. For any exchange, the main part, its heart, is the “matching engine”. There may be several instances of such “engines” and each of them, in the current approximation, can process up to 1 million comparisons per second. Thus, if necessary, we will be able to quickly increase the computational power of the exchange at the lowest cost, simply by adding the necessary number of instances of matching mechanisms.

The tremendous speed of matching between transactions can be achieved only when working in RAM, therefore the matching engine is an in-memory database with the restriction that data loss is unacceptable. Therefore, data on transactions are duplicated in a non-relational database, both before loading into the matching engine, and after matching in order to preserve this important information. In case of system malfunctions at the service level of the matching engine, the instance is simply recreated and all data from the non-relational database is loaded into the in-memory database. Thus, the stable operation of the exchange is guaranteed. The non-relational database also works in a cluster environment with horizontal scaling logic. Thus, on one copy of such a database, there will be orders from the number 0–100,000, on the other 100,001–200,000, etc. Such an architecture guarantees the preservation of the history of transactions in the long term.

As stated in the API specification for the https://docs.escb.exchange, the exchange will support 7 types of applications (orders).

• Market — An order to buy or sell an instrument at the best available price. Contains no restrictions on price or time frame.
• Limit — An order to buy or sell a set amount of an instrument at a specified price or better. A limit order may not be executed if the price set is not met during the time that the order is open.
• StopMarket — An order to buy or sell only when an instrument reaches a set price. Once the instrument reaches this price, the order becomes a market order.
• StopLimit — An order to buy or sell only when an instrument reaches a set price. Once the instrument reaches this price, the order becomes a limit order to buy or sell at the limit price or better.
• TrailingStopMarket — An order that sets the stop price for an instrument at a price with a fixed offset relative to the market price. If the market moves and the stop price is reached, the order becomes a market order.
• TrailingStopLimit — An order that recalculates the stop price for an instrument at a fixed offset relative to the market price. It also recalculates the limit price based on a different fixed offset. If the market reaches the stop price, the order becomes a limit order.
• BlockTrade — A privately executed trade.

After comparing transactions and finding the best parameters for its conduct between the parties, the process will be held directly between the parties with the participation of HMW on the blockchain. Thus, we implement a decentralized approach for conducting transactions with centralization by the platform itself for quick search and comparison of the most favorable conditions for both parties.

Since, in our opinion, any excessive centralization is harmful for the exchange, we will publish the source code of the exchange platform so that everyone can create their own exchange platform based on the ESCB9 protocol. Everyone can also integrate its applications with exchange platforms via API. For example, it will be useful to raise funds during an ICO. Participants will be able to invest any asset without the need to convert it; the exchange API will do it for the user.

If we describe the logical chain of conducting transactions briefly, then we get the following algorithm for the exchange based on the ESCB9 protocol:

• Party A wants to exchange 1 ETH at the rate of $ 200 and places an order for an operation on the exchange platform
• Side B places an order to buy 1 ETH at the rate of $ 200 on the exchange platform
• The matching engine compares the orders of the parties A and B and determines that the transaction can be made
• The exchange platform attaches to one of the HMW dealers Smart contract deal and sets InProcess status for orders
• The Exchange website sends a notification to Side A with instructions for replenishing the deposit for the transaction, which is described in the Smart Contract

The website of the exchange sends a notification to party B with a warning about the transaction in a certain time window on the fixed conditions
After replenishing the deposit by party A within a certain time frame, information is sent to party B for transfer of $ 200 to party A
After acknowledgment of receipt by party A of the agreed $ 200, a deposit at the address of the HMW dealer will be sent to party B
The HMW structure records data about the transaction and sets a rating for counterparties

Orders on the exchange platform are placed in FullyExecuted

As we see such a chain eliminates the risk of an exit-scam and the transaction itself is made between two counterparties in a safe way. The transaction itself can be carried out exclusively on the blockchain, while the exchange platform is used for the convenience of making such transactions in an intuitive format.

If a deal between counterparties is made on a third-party blockchain platform, for example, buying 0.1 BTC for $ 650, then it is conducted using Oracle. That is, with the help of such an auxiliary Smart contract, which allows you to link the Ethereum blockchain with the outside world. The Oracle contract allows you to write data from the outside world to the blockchain only from a specific wallet address. Data for recording will be provided by special utilities for working with each of the external sources. Thus, the operation on the Bitcoin blockchain can be recorded on the Ethereum blockchain in a safe way. Each HMW dealer will have its own Oracle contract, which will reduce the risk of an attack on such a node of the Trust System.

Each operation involving HMW will contain a commission for services, which will be calculated individually for the parties to the transaction depending on the rating in HMW, the number of ESCB tokens, etc. The commission will be spent on maintaining the network and distributing dividends between ESCB token holders.

Legal regulation of transactions
ESCB foundation provides community software and does not participate in the financial activities of the network, so our organization does not need to obtain any licenses for its activities. Transactions take place directly between the parties using the secure escrow mechanism using the ESCB9 protocol. The structure of the HMW may include financial agents and dealers who have licenses for certain activities upon request and to comply with the local law of the parties to the transactions.