In the last article, we made a simple grid strategy together. In this article, we upgraded and expanded this strategy into a multi species spot grid strategy, and let this strategy be tested in practice. The purpose is not to find a "holy grail", but to discuss various problems and solutions when designing strategies. This article will explain some of my experience in designing this strategy. The content of this article is slightly complicated and it requires a certain foundation in programming.
Design thinking based on strategic needs
This article, like the previous one, still discusses design based on the FMZ Quant (FMZ.COM).
Multi-species
To put it bluntly, I think this grid strategy can not only do BTC_USDT, but also LTC_USDT/EOS_USDT/DOGE_USDT/ETC_USDT /ETH_USDT. Anyway, the spot trading pairs and the varieties that want to run are all traded on the grid at the same time.
Hmm~ It feels good to capture the volatile market of multiple species.
The requirement sounds very simple, and the problem comes when designing.
- First, the market quotations of multiple varieties are obtained. This is the first problem to be solved. After consulting the exchange's API documentation, I found that most exchanges provide aggregated market interfaces.
OK, use the aggregated market interface to obtain data. - The second problem encountered is account assets. Because it is a multi species strategy, it is necessary to consider the management of each trading pair asset separately. And we need to get data for all assets at once, and record them. Why do we need to get the account asset data? Why do we need to separate the records of each pair?
Because you need to judge the available assets when placing an order. Is it necessary to obtain it before judging it?
And you need to calculate the profitis, is it also necessary to record an initial account asset data first, then obtain the current account asset data and compare it with the initial one to calculate the profit and loss?
Fortunately, the asset account interface of the exchange usually returns all currency asset data, we only need to obtain it once, and then process the data. - Strategy parameter design. The parameter design of multi species is quite different from the parameter design of single-variety, although the trading logic of each variety of multi-variety is the same, it is possible that the parameters during trading are different. For example, in the grid strategy, you may want to trade 0.01 BTC each time when doing BTC_USDT trading pair, but it is obviously inappropriate to use this parameter (trading 0.01 coins) when doing DOGE_USDT. Of course, you can also deal with the USDT amount. But there will still be problems. What if you want to trade 1000U for BTC_USDT and 10U for DOGE_USDT? The demand can never be satisfied.
There may be someone who will think about this problem and then ask: "I can set several sets of parameters to control the parameters of different trading pairs to be done separately."
This is still not flexible enough to meet the needs, how many sets of parameters are good to set? Three sets of parameters are set, what if I want to make 4 varieties? Do I have to modify the strategy and increase the parameters?...
Therefore, when designing the parameters of the multi species strategy, it is necessary to fully consider the needs of such differentiated parameters. One solution is to design the parameters as ordinary strings or JSON strings.
For example:
ETHUSDT:100:0.002|LTCUSDT:20:0.1
Among them, "|" divides the data of each species, which means that ETHUSDT:100:0.002 controls the ETH_USDT trading pair, and LTCUSDT:20:0.1 controls the LTC_USDT trading pair. The middle "|" is used to divide.
ETHUSDT:100:0.002, where ETHUSDT indicates what the trading pair you want to do, 100 is the grid spacing, 0.002 is the number of ETH coins traded in each grid, and the ":" is to divide these data (of course, these parameter rules are made by the strategy designer, you can design anything according to your needs).
These strings contain the parameter information of each species you want to do. Parse these strings in the strategy, and assign values to the variables of the strategy to control the trading logic of each species. How to parse it? Still use the above example.
function main() {
var net = [] // The recorded grid parameters, use the data when running to the grid trading logic
var params = "ETHUSDT:100:0.002|LTCUSDT:20:0.1"
var arrPair = params.split("|")
_.each(arrPair, function(pair) {
var arr = pair.split(":")
var symbol = arr[0] // Trading pair name
var diff = parseFloat(arr[1]) // Grid spacing
var amount = parseFloat(arr[2]) // Grid order volume
net.push({symbol : symbol, diff : diff, amount : amount})
})
Log("Grid parameter data:", net)
}
Looking at this, the parameters are parsed. Of course, you can also use JSON strings directly, which is simpler.
function main() {
var params = '[{"symbol":"ETHUSDT","diff":100,"amount":0.002},{"symbol":"LTCUSDT","diff":20,"amount":0.1}]'
var net = JSON.parse(params) // The recorded grid parameters, use the data when running to the grid trading logic
_.each(net, function(pair) {
Log("Trading pairs:", pair.symbol, pair)
})
}
- Data durability
There is also a big difference between the strategies that can be applied into practice and the tutorial strategies. The tutorial strategies in the previous article are only a preliminary test of strategy logic and design, and there are more issues to consider when it comes to the real world. In real bot, it is possible to start and stop the real trading. At this time, all the data during the real bot operation will be lost. So how to make the real bot restart to continue running in the previous status after it stopped?
Here, it is necessary to save the key data persistently when the real bot is running, so that the data can be read and continued to run when it is restarted.
You can use the _G() function on the FMZ Quantitative Trading Platform, or use the database operation function DBExec(), and you can check the FMZ API documentation for details.
For example, we design a tail sweep function and use the _G() function to save grid data.
var net = null
function main() { // Strategy main functions
// Read the stored net first
net = _G("net")
// ...
}
function onExit() {
_G("net", net)
Log("Perform tail-sweeping processing and save data", "#FF0000")
}
function onexit() { // The exit sweep function defined by the platform system, triggered the execution when the real bot is clicked to stop
onExit()
}
function onerror() { // The abnormal exit function defined by the platform system, triggered the execution when the program is abnormal
onExit()
}
Limits such as order quantity precision, order price precision, minimum order quantity, and minimum order amount, etc.
The backtesting system does not impose such strict restrictions on the order amount and order accuracy, but each exchange can have strict standards for the price and order amount when placing an order in the real bot, and these restrictions are not the same in different exchanges. Therefore, there are beginners who test in the backtesting system without problems. Once the real bot is launched, there are various problems when the trading is triggered, and then the content of the error message is not read, and various crazy phenomena appear.
To be continued...