FMZ Quant Trading Platform Custom Protocol Access Guide

We FMZ Quant Trading Platform supports many cryptocurrency exchanges and encapsulates the mainstream exchanges on the market. However, there are still many exchanges that are not encapsulated. For users who need to use these exchanges, they can access them through the FMZ Quant Custom Protocol. Not only limited to cryptocurrency exchanges, any platform that supports the REST protocol or FIX protocol can also be accessed.

This article will take REST protocol access as an example to explain how to use the custom protocol of the FMZ Quant Trading Platform to encapsulate and access the API of the OKX exchange. Unless otherwise specified, this article refers to the REST custom protocol.

The workflow of the custom protocol is:
Request process: Strategy instance running on the docker -> Custom protocol program -> Exchange API
Response process: Exchange API -> Custom protocol program -> Strategy instance running on the docker

1. Configure the Exchange

The page for configuring the exchange on the FMZ Quant Trading Platform:

https://www.fmz.com/m/platforms/add

Select protocol: Select "Custom Protocol".
Service address: The custom protocol program is essentially an RPC service.
Therefore, it is necessary to specify the service address and port clearly when configuring the exchange. In this way, the docker knows where to access the custom protocol program during the process Strategy instance running on the docker -> Custom protocol program.
For example: http://127.0.0.1:6666/OKX, the custom protocol program and the docker are usually run on the same device (server), so the service address is written as the local machine (localhost), and the port can be used as a port that is not occupied by the system.
Access Key：
The exchange configuration information passed during the process Strategy instance running on the docker -> Custom protocol program.
Secret Key：
The exchange configuration information passed during the process Strategy instance running on the docker -> Custom protocol program.
Tag:
The tag of the exchange object on the FMZ Quant Trading Platform, used to identify a certain exchange object.

The screenshot of the OKX plug-in configuration disclosed in the article is as follows:

OKX exchange secret key configuration information:

accessKey:  accesskey123    // accesskey123, these are not actual keys, just for demonstrationsecretKey:  secretkey123
passphrase: passphrase123

2. Deployment of the Docker and the Custom Protocol Program (plugin)

1. Docker
  A docker must be deployed to run any strategy on the FMZ Quant Trading Platform. For details on how to deploy a docker, please refer to the platform tutorial. It will not go into details here.
1. Custom Protocol Program (plugin)
  Docker and the custom protocol are usually deployed on the same device. The custom protocol (service) program can be written in any language. This article is written in Python3. Just like running any Python program, you can execute it directly (make various configurations of the Python environment in advance).
  Of course, FMZ also supports running python programs, and you can also run this custom protocol as a live trading to provide the FMZ Quant Trading Platform with support for unpackaged exchange API access.
  After the custom protocol program is running, it starts listening: http://127.0.0.1:6666. The custom protocol program can process specific paths, such as /OKX.

3. Strategy Instance Requests FMZ API Function

When the (FMZ) platform API function is called in the strategy, the custom protocol program will receive a request from the docker. You can also test it using the platform's debugging tools, for example:

Debugging tools page:

https://www.fmz.com/m/debug

functionmain() {
    return exchange.GetTicker("LTC_USDT")
}

Calling the function exchange.GetTicker(), the custom protocol program receives the request:

POST /OKXHTTP/1.1 
{
    "access_key":"xxx",
    "method":"ticker",
    "nonce":1730275031047002000,
    "params":{"symbol":"LTC_USDT"},
    "secret_key":"xxx"
}

access_key: The exchange key configured in the platform "Configure Exchange" above
secret_key: The exchange key configured in the platform "Configure Exchange" above
method: related to the calling interface in the strategy, when calling exchange.GetTicker(), method is ticker.
nonce: The timestamp when the request occurred.
params: Parameters related to the interface call in the strategy, in this example, when calling exchange.GetTicker(), the related parameters are: {"symbol":"LTC_USDT"}.

4. Custom Protocol Program Access to Exchange Interface

When the custom protocol program receives a request from the docker, it can obtain information such as the platform API function (including parameter information) requested by the strategy, the exchange key, etc. based on the information carried in the request.

Based on this information, the custom protocol program can access the exchange interface to obtain the required data or perform certain operations.

Usually the exchange interface has methods such as GET/POST/PUT/DELETE, which are divided into public interface and private interface.

Public interface: an interface that does not require signature verification and is directly requested in a custom protocol program.
Private interface: an interface that requires signature verification. The signature needs to be implemented in the custom protocol program to request the API interface of these exchanges.

The custom protocol program receives the response data from the exchange interface and further processes it to construct the data expected by the docker (described below). Refer to OKX spot exchange, the GetTicker, GetAccount and other functions in the CustomProtocolOKX class implementation in the Python custom protocol example.

5. The Custom Protocol Program Responds the Data to the Docker

When the custom protocol program accesses the exchange's API interface, performs certain operations or obtains certain data, it needs to feed back the results to the docker.

The data fed back to the docker varies according to the interface called by the strategy, and is first divided into two categories:

The custom protocol program calls the exchange interface successfully:

{
    "data": null,  // "data" can be of anytype"raw": null    // "raw" can be of anytype 
}

data: The specific structure of this field is related to the method in the request received by the custom protocol program, and is used to construct the data structure finally returned by the FMZ platform API function. All interfaces will be listed below.
raw: This field can be used to pass in the raw data of the exchange API interface response, such as the Ticker structure returned by the exchange.GetTicker() function. The Info field of the Ticker structure records the data of the raw field and the data field; some of the platform's API functions do not need this data.

The custom protocol program failed to call the exchange interface (business error, network error, etc.)

{
    "error": ""    // "error" contains an error message as a string
}

error: error information, which will be displayed in the error log in the log area of the (FMZ) platform live trading, debugging tool and other pages.

Demonstrates the custom protocol response data received by the strategy program:

// Tested in the debugging tool of the FMZ platformfunctionmain() {
    Log(exchange.GetTicker("USDT"))       // The trading pair is incomplete, the BaseCurrency part is missing, and the custom protocol plug-in is required to return an error message: {"error": "..."}Log(exchange.GetTicker("LTC_USDT"))
}

6. Data Structure Agreement in Custom Protocol

The above is a brief process of the custom protocol program participating in the access to the (FMZ unpackaged) exchange API. This process only explains the process when calling the exchange.GetTicker() function in the (FMZ) platform debugging tool. The following will explain the interaction details of all platform API functions in detail.

The platform encapsulates the common functions of various exchanges and unifies them into a certain function, such as the GetTicker function, which requests the current market information of a certain product. This is an API that basically all exchanges have. Therefore, when accessing the API interface encapsulated by the platform in a strategy instance, the docker will send a request to the "Custom Protocol" plug-in program (mentioned above):

POST /OKXHTTP/1.1 
{
    "access_key": "xxx",
    "method": "ticker",
    "nonce": 1730275031047002000,
    "params": {"symbol":"LTC_USDT"},
    "secret_key": "xxx"
}

When calling different FMZ platform encapsulated API functions in the strategy (such as GetTicker), the request format sent by the docker to the custom protocol will also be different. The data (JSON) in the body only differs in method and params. When designing a custom protocol, perform specific operations according to the content of the method. The following are the request-response scenarios for all interfaces.

Spot Exchange

For example, the current trading pair is: ETH_USDT, which will not be described in detail later. The data that the docker expects the custom protocol to respond to is mainly written in the data field, and a raw field can also be added to record the original data of the exchange interface.

GetTicker

method field: "ticker"
params field:

{"symbol":"ETH_USDT"}