Live Robot Billing and Top-up

Billing

• Live robots are billed by the hour at 0.05 USD per robot per hour; a partial hour counts as a full hour.
• Billing starts when the robot is created, and starting it prepays the first hour, so a robot cannot start if the account balance is insufficient. Stopping or restarting a robot does not bill it twice.
• If the balance runs out while a robot is running, the platform stops the robot; when a rented strategy expires, the robots using it are stopped as well.
• Servers rented with one-click docker rental are billed separately from live robots (see Platform Basics → Docker → Deploy Docker → One-Click Docker Rental).

Bills and balance alerts

• The billing page shows the balance, top-up records and every billing item.
• Under balance alert in account settings, set an alert threshold: when the available balance drops below it you get an email and WeChat notification (at most once every 24 hours unless you top up or change the setting); 0 turns the alert off.

Top-up
Choose the payment method and amount on the billing page. When topping up with USDT, check carefully:

• The transfer network must match the network selected on the billing page; TRC20, ERC20 and BSC are supported. ERC20 and BSC addresses both start with 0x and look the same, which makes them the easiest to mix up.
• The asset is USDT.
• The destination address is the one shown on the billing page.

Sub-accounts

A sub-account lets other people view and operate some of your live robots without giving them the main account.

Create a sub-account
On the account settings page, open the sub-account tab, select the live robots the sub-account may access under operation permissions, enter its username and login password, and create it. Sub-accounts are listed on the same page, where you can edit, lock/unlock or delete them.

Permissions
A sub-account sees only the live robots authorized to it. On those robots it can change parameters, stop and restart, but it cannot change the exchange objects configured for the robot.

Typical uses

• A quant team sharing the management of several live robots.
• Letting the renter of a strategy help debug a live robot.

General Protocol

For exchange API interfaces that have not yet been encapsulated and integrated by the FMZ Quant Trading Platform, you can access them by writing general protocol plugin programs.

This general protocol can be used to access any exchange that provides API interfaces, supporting the following two protocols:

• REST Protocol: Reference Documentation.
• FIX Protocol: Reference Project.

The difference between FIX protocol plugin programs and REST protocol plugin programs lies only in the interaction method between the plugin program and the exchange interface. The interaction method, data format, and other implementation details between the protocol plugin program and the FMZ Quant docker program are exactly the same. For specific implementation, please refer to the examples in the above links.

Local Credential Files

When configuring an exchange, every masked encrypted input (Secret Key, private key, password, etc.) can hold a credential file path file:///name.txt instead of the secret itself. When the live robot runs, the docker reads that file on its own machine and uses the content as the value. The private key then exists only on the docker's machine, and the platform stores nothing but a path.

Path rules

• The path is resolved relative to this robot's directory logs/storage/<robot ID>/ (logs is under the docker's working directory). For robot ID 123456, file:///rsaKey.txt means logs/storage/123456/rsaKey.txt.
• Subdirectories are allowed, e.g. file:///keys/rsaKey.txt.
• Only the .txt suffix is recognized; with any other suffix the text is not read as a file but used literally as the configuration value.
• The path cannot be absolute, cannot contain .., and after resolution cannot leave the robot directory (symbolic links pointing outside are rejected too).
• Credential files are read from each robot's own directory, so when several robots use the same exchange configuration, every robot directory needs its own copy.
• If the file cannot be read, the robot fails to start with an error containing read key file; an invalid path fails with key file path must be relative and cannot contain '..' or key file path escapes the robot directory.

Example: an RSA key
For an exchange that supports RSA KEY authentication:

1. Generate an RSA public/private key pair, e.g. a PKCS#8 pair with openssl.
2. Create an RSA KEY on the exchange and upload the public key from step 1.
3. Configure the exchange on the platform: put the exchange's RSA KEY in Access Key and file:///rsaKey.txt in Secret Key.
4. Create the live robot and note its ID (e.g. 123456).
5. Save the private key from step 1 as logs/storage/123456/rsaKey.txt, then start (or restart) the robot.

See the video walkthrough (Chinese) for the full process.

Exchange-Specific Notes

Configuration steps of individual exchanges and the places where they behave differently from the general API. Exchanges not listed here follow the general descriptions in the syntax manual; the switches each exchange supports through exchange.IO() are listed under exchange.IO.

Deploy Docker

The docker management page lists the dockers of your account, as a list or with details, including each docker's IP address, version and build time. Click Deploy Docker to open the docker deployment page, which offers two ways: one-click docker rental and manual deployment.

            bash
            
            
chmod +x robot                      # Linux/macOS: make it executable before the first run
./robot -s node.fmz.com/123456      # prompts for the password, which is not echoed

            bash
            
            
cat > robot.conf <<'EOF'
s=node.fmz.com/123456
p=your-password
EOF
chmod 600 robot.conf
./robot -c robot.conf               # with robot.conf in the startup directory, plain ./robot loads it too

            ini
            
            
[Unit]
Description=FMZ robot
After=network-online.target
Wants=network-online.target

[Service]
WorkingDirectory=/opt/robot
ExecStart=/opt/robot/robot -c /opt/robot/robot.conf
Restart=on-failure
TimeoutStopSec=90

[Install]
WantedBy=multi-user.target

            bash
            
            
sudo systemctl daemon-reload
sudo systemctl enable --now robot

Command-Line Options

Starting the command-line docker program robot:

            bash
            
            
./robot -s node.fmz.com/123456            # prompts for the password (not echoed)
./robot node.fmz.com/123456               # short form: robot address [password]
./robot -c robot.conf                     # read options from a configuration file
./robot -v                                # show the version

Options

Options that take a value can also be written as -option=value, e.g. -n=server01. An invalid option prints the usage and exits.

Configuration file robot.conf
One key=value per line; the key is the option name without - (s p n w u I d i e f H vv), and lines starting with # are comments:

            ini
            
            
# robot.conf
s=node.fmz.com/123456
p=your-password
n=server01
vv=true

• Give the file with -c; without -c and without an address, robot.conf in the startup directory is loaded automatically if present.
• When an option is given both on the command line and in the file, the command line wins.
• Keys are case-sensitive: I is the outbound IP and i the Docker image.
• The configuration file path and -f @file are resolved relative to the startup directory (before -w changes directory).
• The file holds your password, so make it readable only by you (chmod 600 robot.conf).

Pinning the outbound IP (-I)
When the server has several IP addresses and the exchange API key is whitelisted for one of them, pin the outbound IP with -I, e.g. ./robot -s node.fmz.com/123456 -I 192.168.1.100. The connection to the platform and the strategies' connections to exchanges then leave from that address. With -i container isolation the container's network may not have that address; in that case let the container use the host network.

The Windows GUI version has no IP setting; use the command-line version when you need to pin the outbound IP. The GUI version accepts only -s, -p and -n, which prefill the window; when both -s and -p are given it starts automatically.

Live Trading Data Migration

Each live robot's data is in logs/storage/<robot ID>/ under the docker's working directory (the database <robot ID>.db3, stdout.log, stderr.log and so on). The logs, profit and charts the platform shows for a robot are read from the docker that runs it.

Moving one robot to a docker on another machine

1. Stop the robot.
2. Copy the whole logs/storage/<robot ID>/ directory to the same place under the new docker's working directory, keeping the robot ID as the directory name.
3. Switch the robot's docker to the new one in the robot configuration and start the robot.

The robot's existing logs, profit and other data are then kept on the new machine.

Moving a whole docker

1. Stop the robots on the old docker, then stop the old docker.
2. Copy the entire logs directory from the old docker's working directory to the working directory on the new machine.
3. Start the docker on the new machine.

logs/docker.pid holds the docker's identity: with the old docker offline, the docker on the new machine gets the old docker ID back, so robot configurations need no change. Never run dockers on two machines with the same logs directory at the same time.

Docker Monitor

On the docker management page, Docker Monitor can be enabled from the actions of the docker list or of the docker details. Once enabled, the platform emails the address bound to your account when the docker goes offline abnormally.

Import and Export of Complete Strategies

Copying the source code is not enough to move a strategy: the parameter design, interaction design, template references and more are not in the source. "Export Strategy" and "Import Strategy" on the strategy editing page move a strategy completely.

• Export Strategy
  Exports one xml file, for strategies in every programming language. When exporting you can choose what to include: name, source code, notes, description, manual, template references, strategy parameters, interactive controls and backtest settings.

• Import Strategy
  Click "Import Strategy" on the strategy editing page, choose an xml file produced by "Export Strategy", and select what to import. Click "Save" afterwards to save the strategy.

Strategy Sharing and Renting

On the Strategy Library page, click the "Actions" button on the right side of a strategy to display a menu containing sharing and renting options.

Important Notice: When creating and distributing strategy registration codes, please carefully confirm whether it is a "Registration Code" or "Copy Code" to avoid accidentally leaking your strategy.

Grouping

Click the Group Management button on the right of the "Live Trading" page or the "Strategy Library" page to group robots or strategies; group names are up to you.
For strategies, for example, you can put template libraries in one group, JavaScript strategies in another and test strategies in a third.

• Strategy groups
  

• Robot groups
  

Live Trading Observation

Click the "Public" button in the live trading list on the Live Trading Page of FMZ Quant Trading Platform to publicly display the current live trading instance.

Live trading observation currently supports two methods:

• 1. Publicly display live trading on the Live Trading Observation page of FMZ Quant Trading Platform. Click the "Public" button and select Public Sharing.
• 2. Create a private link for live trading observation.
     Click the "Public" button and select Internal Sharing, set the validity period to generate a private link for accessing the private observation page of this strategy's live trading.

Live Trading Message Push

You can enable the message push feature on the Push Settings page.

• Mobile (App)
  After enabling mobile App push, push messages sent by the live trading program will be delivered to the FMZ Quant mobile App.
• Email
  To enable email push, you must first verify your email address. Once verified, you can receive push messages sent by the live trading program.
• WebHook
  After enabling WebHook push, you can customize the push address, for example: http://abc.com/push.php?data={body}.
  When the live trading program sends a push message, the platform will send a request to the configured address http://abc.com/push.php?data={body} (only the GET method is supported), and the pushed message content will replace the {body} placeholder.

Pushing Messages in Strategies

• JavaScript/TypeScript/Python/Rust Languages
  In the strategy code, you can use the Log() function as well as other functions that output log information in the log area, such as exchange.CreateOrder(), exchange.CancelOrder(), etc.
  By passing an additional parameter "@" to these functions (i.e., adding an extra parameter beyond the required ones), for example Log("This is a push message", "@"), the output log information will be pushed, and the platform will push the message according to the "Push Settings". In the Rust language, the corresponding Log! macro is used the same way: Log!("This is a push message", "@");.
• PINE Language/My Language
  In the "Trading Library" parameters integrated into PINE Language/My Language strategies, you can enable trading log push, which will automatically push messages after a trading action is triggered.
• Blockly Visual
  In the "Tools" section, select the Message Push module to push specified information.

Message push is subject to a frequency limit, with the following rule: within each 20-second cycle of live trading, only the last message is retained and pushed, while all other messages are filtered out and not pushed.

Common Causes of Live Trading Errors and Abnormal Exits

The robot cannot start

• No online docker
  A robot cannot start while its docker is offline. Check on the docker page that the docker is online, or pick another online docker.
• Insufficient balance
  Starting a robot prepays its first hour, so it cannot start without enough balance; if the balance runs out while it runs, the platform stops it. Top up and start it again (see Platform Basics → Account and Billing → Live Robot Billing and Top-up).
• Rented strategy expired or concurrency limit reached
  When a rented strategy expires, robots using it are stopped and cannot be started again; once the rental's maximum number of concurrent robots is reached, no further robot can start.
• Key decryption failed
  The error contains secret key decrypt failed (wrong password). The FMZ account password was changed, so the exchange keys configured earlier can no longer be decrypted. To fix it:
  1. Re-enter the exchange keys, passwords and similar fields on the Exchange management page.
  2. Stop all dockers and start them again with the new password.
• Credential file not found
  The exchange configuration uses a file:///xxx.txt credential file that is missing from the robot directory; the error contains read key file. An invalid path fails with key file path must be relative and cannot contain '..' or key file path escapes the robot directory. See Platform Basics → Exchange → Local Credential Files.

Errors caused by strategy code

• Static syntax errors

  

  These are obvious: the strategy editing page usually marks them, and a backtest reveals them too.

• Runtime errors
  The most common one is using a function's return value without checking that it is valid.

• Excessive memory usage
  Keeping too much data that cannot be garbage-collected in global variables.

• Improper use of exchange.Go for concurrent requests
  Calling the asynchronous exchange.Go without calling wait for the results in time, so that too many concurrent tasks pile up.

• Recursion too deep
  Too many levels of recursion exceed the call stack size.

Other errors

• API business errors and network request errors
  These show the exchange object name, the function name, the error message and the reason, and do not stop the robot by themselves. They are usually the trigger rather than the direct cause, which is typically a program exception from using an API return value without checking it.
• interrupt error
  Logged when the user clicks the Stop button on the robot page while the program is in the middle of an operation (such as an exchange API call) and the stop interrupts it. It is harmless, just a log entry.

See the FAQ collection for more.