The network provides the tools to set up your testing and live-trading environments, as well as the definitions on where on the network processes run, and where data is stored.

Network

Network Node

Data Mining

Exchange Data Tasks

Market Data Tasks

Data Mine Tasks

Task Manager

Task

Sensor Bot Instance

Sensor Process Instance

Indicator Bot Instance

Indicator Process Instance

Time Frames Filter

Key Reference

Testing Environment

Exchange Trading Tasks

Market Trading Tasks

Trading Mine Tasks

Task Manager

Task

Trading Bot Instance

Trading Process Instance

Backtesting Session

Paper Trading Session

Parameters

Session Base Asset

Session Quoted Asset

Time Range

Time Frame

Slippage

Fee Structure

Snapshots

Heartbeats

User Defined Parameters

Trading System Reference

Trading Engine Reference

Execution Started Event

Key Reference

Production Environment

Exchange Trading Tasks

Market Trading Tasks

Trading Mine Tasks

Task Manager

Task

Trading Bot Instance

Trading Process Instance

Forward Testing Session

Live Trading Session

Parameters

Session Base Asset

Session Quoted Asset

Time Range

Time Frame

Slippage

Fee Structure

Snapshots

Heartbeats

User Defined Parameters

Trading System Reference

Trading Engine Reference

Execution Started Event

Key Reference

Data Storage

Data Mines Data

Exchange Data Products

Market Data Products

Data Mine Products

Bot Products

Data Product Folder

Data Product

Data Product

Trading Mines Data

Exchange Trading Products

Market Trading Products

Session Reference

Trading Mine Products

Bot Products

Data Product Folder

Data Product

Data Product

Network

The network hierarchy provides the control functions for running data-mining and trading operations. Because operations may be run either on a single machine or distributed over a network of machines, it also contains definitions regarding the physical location in which nodes live or function.

The network hierarchy defines where in the network you run each of the bots you choose to run, and where the data they output is stored.

You will use the network hierarchy for the following purposes:

  • To control your data mining operation—that is, tasks running sensor and indicator bots. Data mining tasks process data that may be consumed by others; for example, so that your trading systems may count with quality information.

  • To control your testing environment—that is, trading sessions including backtesting and paper trading sessions.

  • To control your production environment—that is, forward testing, and live trading sessions.

  • To manage the storage of the data produced by the bots you run as outputs. This includes administering the physical locations on which the data products produced by bots reside.

Network Node

A network node represents a machine running Superalgos, on which processes run and data is stored.

By default, processes are set up to run locally in a network node representing your local machine. However, the system is prepared to run distributed on a network of nodes, or what we call a trading farm.

You may create unlimited network nodes and map them with different machines on a network. Each machine in the network runs an instance of the Superalgos backend, and you may control the whole network operation from a single machine, or—in general—from any machine in the network running the Superalgos frontend. To learn more about distributed setups, check the trading farms pages.

The easiest and fastest way to set up a network node is using the Install Market function available on markets defined in the Crypto Ecosystem hierarchy, under the exchange markets node. This function adds data mining tasks for all sensor and indicator bots shipping with the system, backtesting and live trading tasks for trading systems shipping with the system, including the data storage definitions for both, and also creates the corresponding dashboards and charts in the Charting Space hierarchy. You may learn more about this function in the how to install a new market page.

If you need finer control over the operation you wish to deploy on the network, then you may use the individual functions available under each section of the hierarchy under the network node.

Adding a Network Node

To add a network node, select Add Network Node on the Superalgos Network node menu. A network node is added along with the basic structure of nodes to set up a node.

Configuring the Network Node

Select Configure Network Node on the menu to access the configuration.

{ 
"host": "0.0.0.0", 
"webPort": "34248", 
"webSocketsPort": "18041"
}
  • host is the machine or hardware represented by the network node, which must be identified by its IP address.

  • webPort is the port used by the Web Server, at this stage 34248.

  • webSocketsPort is the port used by the system to communicate over the local area network, by default set at 18041.

Data Mining

Data mining is the activity of processing data. You need to process data to feed charts, and so that your trading systems may make decisions based on quality information.

Having access to quality information is a crucial element of trading. For that reason, Superalgos strives to give users full control over how, where, and when data is processed. You will use this section of the network hierarchy to exert that control.

Data mining is done through tasks running instances of sensor and indicator bots. The data structure under this node allows organizing the data mining operation by exchange, market, and data mine.

The setup of the data mining operation may be done using the Install Market function of the market you wish to install as defined in the Crypto Ecosystem hierarchy under the exchange markets node. Learn more about this function on the how to install a new market page.

You may also set up data mining tasks by using the different functions in this section of the hierarchy, starting with the options in the menu of this node. This route offers finer control over what tasks you set up, and how.

Exchange Data Tasks

The exchange data tasks node organizes data mining tasks by exchange. That is, each exchange installed in the system has an exchange data tasks node grouping all market data tasks corresponding to the said exchange.

The exchange data tasks node must reference the exchange of choice. This reference constraints the rest of the definitions to the context of the said exchange.

When representing an exchange featured in the system’s icons library, the standard exchange data tasks icon is replaced by the exchange’s logo.

Adding an Exchange Data Tasks Node

To add a specific exchange data tasks node, select Add Exchange Data Tasks on the parent node menu.

You may also add exchange data tasks node in bulk for all exchanges that may have been previously defined in the Crypto Ecosystem hierarchy. To do that, select Add Missing Exchanges on the parent node menu. An exchange data tasks node is created for each defined exchange, each with the corresponding reference.

Starting an Exchange Data Tasks Node

Select Run All Market Data Tasks or Stop All Market Data Tasks on the menu to start and stop all tasks under this node.

Market Data Tasks

A market data tasks node groups data mining tasks operating in a specific market.

The market data tasks node must reference a market defined in the Crypto Ecosystem hierarchy.

This node may spawn individual data products or may deploy data products in bulk organized by data mine and by bots. See the data products node for the details.

Adding a Market Data Tasks Node

To add a market data tasks node, select Add Market Data on the parent node menu.

You may also add market data tasks nodes in bulk for all markets that may have been previously defined in the Crypto Ecosystem hierarchy. To do that, select Add Missing Markets on the parent node menu. A market data tasks node is created for each defined market, each with the corresponding reference.

Starting a Market Data Tasks Node

Select Run All Data Mine Tasks or Stop All Data Mine Tasks on the menu to start and stop all tasks under this node.

Data Mine Tasks

The data mine tasks node is an organizational device that groups tasks corresponding to the referenced data mine.

The data mine tasks node must reference the definition of a data mine. The node may spawn tasks for each bot in the data mine.

Adding a Data Mine Tasks Node

To add a data mine tasks node, select Add Data Mine Tasks on the parent node menu. This action adds the node but does not establish a reference with any data mine.

The smarter use of the node involves using the Add Missing Data Mine Tasks option on the parent node menu. This action creates a data mine tasks node for each data mine in the workspace, establishing a reference with the corresponding data mines. This is the first step in the direction of quickly setting up tasks for each bot in a given data mine.

Starting a Data Mine Tasks Node

Select Run All Task Managers or Stop All Task Managers on the menu to start and stop all tasks under this node.

Task Manager

A task manager is a device used to organize and control any number of tasks, which, in turn, control bot instances. You use a task manager to start or stop several tasks at the same time.

Task managers are used both in the context of data mining and trading operations, to facilitate the organization of tasks.

For example, you may set up a task manager to handle tasks related to a particular set of indicators used with a certain strategy. Or, for example, to organize multiple backtesting sessions.

Adding a Task Manager Node

To add a task manager, select Add Task Manager on the parent node menu.

Starting a Task Manager

Select Run All Tasks or Stop All Tasks on the menu to start and stop all tasks respectively.

Task

A task is the device used to control bot instances, that is, to start and stop bots, including sensors, indicators and the trading bot.

Each task controls a single bot. A bot instance running on its own task is independent from other bots at the operating system level, thus, may not be affected by errors ocurring on those other bots.

Adding a Task Node

To add a task, select Add Task on the task manager node menu.

Starting a Task

Select Run on the menu to start a task. When a task is started, the process instance of the bot instance attached to the task is started. Also, a visual indication that both the task and the process instance are running appear surrounding the corresponding nodes, in the form of a progress ring.

To stop a task, select Stop on the menu.

Sensor Bot Instance

A sensor bot instance is a reference to a sensor bot as defined in a data mine. The instance of the bot runs the defined processes and generates the defined data products.

A sensor bot is an algorithm that extracts raw data from external sources (i.e.: exchanges, Twitter, etc.) and stores it in a dataset that other bots may consume.

The sensor bot instance holds no definitions as to what the bot does. Instead, its process instance references a process definition in the corresponding data mine. That is how the sensor bot instance obtains the information regarding what it needs to do once it is run.

Adding a Sensor Bot Instance Node

To add a sensor bot instance, select Add Sensor Bot Instance on the task node menu.

Configuring the Sensor Bot Instance

Select Configure Sensor Bot Instance on the menu to access the configuration.

  {
    "startDate": "2020-01-01"
  }
  • startDate is the desired starting date of the data product the sensor bot instance builds, in the YYYY-MM-DD format. The sensor bot instance queries its data source for data starting on the configured startDate.

    • The actual date in which the dataset starts depends on external factors: A. The market may start at a later date. B. The exchange may limit how far in the past data may be retrieved. In both cases, the sensor bot automatically discovers the date closest to the desired starting date that is possible to start with, and proceeds accordingly.

    • In the case the startDate is changed after the sensor bot has started building a data product, either for an earlier or later date, the sensor re-evaluates the feasibility of starting at the new date. The actual date may or may not change; regardless, the sensor bot discards the existing data product and starts over from the newly discovered date. In other words, if the startDate is changed, the sensor bot starts over.

    • Notice that the above starts a chain reaction among all indicator bots that have a data dependency with the sensor bot’s output dataset. Also, if the actual date ends up changing, all indicators that determine the starting date of the market by looking at the date discovered by the sensor bot have to discard their existing data products and start over from the new date.

Starting a Sensor Bot Instance

You do not start or stop a sensor bot instance directly. Instead, you start or stop the corresponding task.

Sensor Process Instance

A sensor process instance is a reference to the process definition of a sensor bot, as defined in a data mine.

For example, in the case of an instance of the Masters data mine Exchange Raw Data sensor bot, the bot process instance references the Historic OHLCVs process definition. Once the reference is established, the sensor process instance adopts the name of the process definition it references.

Adding a Sensor Process Instance Node

To add a sensor process instance, select Add Sensor Process Instance on the sensor bot instance node menu.

Starting a Sensor Process Instance

You do not start or stop a sensor process instance directly. Instead, you start or stop the corresponding task.

Indicator Bot Instance

An indicator bot instance is a reference to an indicator bot as defined in a data mine. The instance of the bot runs the defined processes and generates the defined data products.

An indicator bot is an algorithm that processes information that other bots have generated, and produces elaborate datasets for others to consume.

The indicator bot instance holds no definitions as to what the bot does. Instead, its processes instances reference the process definitions in the corresponding data mine. That is how the indicator bot instance obtains the information of what it needs to do once it is run.

Adding an Indicator Bot Instance Node

To add an indicator bot instance, select Add Indicator Bot Instance on the task node menu.

Starting an Indicator Bot Instance

You do not start or stop an indicator bot instance directly. Instead, you start or stop the corresponding task.

Indicator Process Instance

An indicator process instance is a reference to the process definition of an indicator bot, as defined in a data mine.

Indicator bot instances usually require two indicator process instances. One of them references the indicator’s multi-period-market process definition and the second references the multi-period-daily process definition.

Once the reference is established, the indicator process instance adopts the name of the process definition it references.

Adding an Indicator Process Instance Node

To add an indicator process instance, select Add Indicator Process Instance on the indicator bot instance node menu.

Starting an Indicator Process Instance

You do not start or stop an indicator process instance directly. Instead, you start or stop the corresponding task.

Time Frames Filter

The time frame filters node allows control over which time frames are to be calculated by each indicator bot instance running on the data mining operation.

Limiting the number of time frames calculated by any given indicator to the few that may be required by a particular trading system has a significant positive impact on performance: it reduces the load on the CPU, the memory requirements, and the requirements of storage space, in proportion with the time frames you remove.

When a time frames filter is set up, a Time.Frames.json file is created by the indicator process in the corresponding output folder. This file is read by others—such as the charting system—to get the information regarding which time frames are available and which are not, to avoid reporting errors.

Adding a Time Frames Filter Node

To add the time frames filter node, select Add Time Frames Filter on the parent node menu.

Configuring the Time Frames Filter

Select Configure on the menu to access the configuration.

{ 
"dailyTimeFrames": [ "45-min", "40-min", "30-min", "20-min", "15-min", "10-min", "05-min", "04-min", "03-min", "02-min", "01-min" ],
"marketTimeFrames": [ "24-hs", "12-hs", "08-hs", "06-hs", "04-hs", "03-hs", "02-hs", "01-hs"]
}
  • dailyTimeFrames features the time frames corresponding to the daily files type of data structure; in practical terms, the time frames below one hour.

  • marketTimeFrames features the time frames corresponding to the market files type of data structure; in practical terms, the time frames of one hour and above.

Key Reference

The key reference is a reference to an exchange account key as defined in a specific user account, in a specific exchange, on the Crypto Ecosystem hierarchy.

Usually, exchanges require autentication via your exchange account key for monetary transactions only. However, some exchanges may require autentication in other contexts as well, for instance, to retrieve information above a certain quota, or to retrieve raw trades data instead of OHLCV data.

For those reasons, exchange key references are available both in the context of data mining and trading operations, and are always attached to the corresponding task.

Forward testing and live trading sessions always require setting up key references, as that is the kind of scenario in which the user must validate with the exchange.

In all cases, the key reference node must reference a valid exchange account key from an account with the exchange, as defined in the Crypto Ecosystem hierarchy.

Adding a Key Reference Node

To add a key reference, select Add Key Reference on the task node menu.

Execution Started Event

The execution started event is the event that triggers the execution of a process. It usually references the execution finished event of another process on which the process depends on.

These references determine when a process is due for another run. By listening to the execution finished event of the process it depends on, it may wake up just in time to process the new batch of data the dependency has just delivered.

Bots form a sort of multi-branched execution sequence with an indeterminate number of dependencies. Every time the bot further down the tree of dependencies finishes a cycle, it triggers the execution of multiple bots listening to its execution finished event.

In the context of a trading process instance running a trading session on the network hierarchy, the execution started event may be used to force the trading process to run only after the last indicator bot dependency finishes its job. This guarantees that all dependencies are up to date and that the trading bot will evaluate the information corresponding to the same candles for all indicators used by the trading system.

Not setting up this event on a trading session may result in eventual data inconsistencies, as—in theory—the trading bot may run with some indicators up to date and some slightly delayed.

Adding an Execution Started Event Node

To add an execution started event, select Add Missing Items on the process definition node menu. Items that may be missing are created along with the basic structure of nodes required to define them.

Testing Environment

The testing environment node organizes trading sessions involving testing of trading systems.

Thorough and comprehensive testing of strategies is at the core of successful trading. Superalgos strives to put you in control of the testing process providing you with flexible tools to fit your criteria.

Depending on how you use the system, how many markets and exchanges you work with, the number of trading systems you use, or the way you choose to test your strategies, you may find yourself with a large number of testing sessions. As explained in the sorting of tasks page, the testing environment helps you organize large numbers of tasks sorting them by exchange, market, and trading mine.

Superalgos handles two types of simulated tests: backtesting and paper trading. Backtesting involves testing over historic data, while paper trading is about testing on a live data stream, but without placing orders at the exchange.

Trading sessions are controlled by a number of parameters that determine how the session is run. The built-in parameters provide great control and flexibility as to how to handle data sets and how to produce the resulting simulations.

Exchange Trading Tasks

The exchange trading tasks node organizes trading tasks by exchange. That is, each exchange installed in the system has an exchange trading tasks node grouping all market trading tasks corresponding to the said exchange.

The exchange trading tasks node must reference the exchange of choice. This reference constraints the rest of the definitions to the context of the said exchange.

When representing an exchange featured in the system’s icons library, the standard exchange trading tasks icon is replaced by the exchange’s logo.

Adding an Exchange Trading Tasks Node

To add a specific exchange trading tasks node, select Add Exchange Trading Tasks on the parent node menu.

You may also add exchange trading tasks node in bulk for all exchanges that may have been previously defined in the Crypto Ecosystem hierarchy. To do that, select Add Missing Exchanges on the parent node menu. An exchange trading tasks node is created for each defined exchange, each with the corresponding reference.

Starting an Exchange Trading Tasks

Select Run All Market Trading Tasks or Stop All Market Trading Tasks on the menu to start and stop all tasks under this node.

Market Trading Tasks

A market trading tasks node groups trading tasks operating in a specific market.

The market trading tasks node must reference a market defined in the Crypto Ecosystem hierarchy.

This node may spawn individual data products or may deploy data products in bulk organized by data mine and by bots. See the data products node for the details.

Adding a Market Trading Tasks Node

To add a market trading tasks node, select Add Market Data on the parent node menu.

You may also add market trading tasks nodes in bulk for all markets that may have been previously defined in the Crypto Ecosystem hierarchy. To do that, select Add Missing Markets on the parent node menu. A market trading tasks node is created for each defined market, each with the corresponding reference.

Starting a Market Trading Tasks

Select Run All Trading Mine Tasks or Stop All Trading Mine Tasks on the menu to start and stop all tasks under this node.

Trading Mine Tasks

The trading mine tasks node is an organizational device that groups tasks corresponding to the referenced trading mine.

The market trading tasks node must reference the definition of a data mine. The node may spawn tasks for each bot in the data mine.

Adding a Trading Mine Tasks Node

To add a trading mine tasks node, select Add Trading Mine Tasks on the parent node menu. This action adds the node but does not establish a reference with any data mine.

The smarter use of the node involves using the Add Missing market trading tasks option on the parent node menu. This action creates a market trading tasks node for each data mine in the workspace, establishing a reference with the corresponding data mines. This is the first step in the direction of quickly setting up tasks for each bot in a given data mine.

Starting a Trading Mine Tasks

Select Run All Task Managers or Stop All Task Managers on the menu to start and stop all tasks under this node.

Trading Bot Instance

A trading bot instance is a reference to the trading bot as defined in the Masters data mine. The instance of the bot runs the defined processes and generates the defined data products.

Based on datasets exposed as products by other bots (counting sensors, indicators and even other trading bots), a trading bot applies the trading logic defined on a trading system to, on one side, generate a complete trading simulation (outputting datasets that include trades, the action of strategies, validation of conditions, etc.), and on the other side, manage the execution of orders when on a forward testing or live trading session.

The trading bot instance holds no definitions as to what the bot does. Instead, its process instance references the process definition in the Masters data mine. That is how the indicator bot instance obtains the information of what it needs to do once it is run.

Adding a Trading Bot Instance Node

To add a trading bot instance, select Add Trading Bot Instance on the task node menu. When a trading bot instance is added, it is created with one trading process instance, and a market reference.

Starting a Trading Bot Instance

You do not start or stop a trading bot instance directly. Instead, you start or stop the corresponding task.

Trading Process Instance

A trading process instance is a reference to the process definition of the trading bot, as defined in the Masters data mine.

The trading process instance must reference the Multi-Period process definition of the Jason trading bot in the Masters data mine.

Adding a Trading Process Instance Node

To add a trading process instance, select Add Trading Process Instance on the trading bot instance node menu. When a trading process instance is added, it is created with a market reference.

Starting a Trading Process Instance

You do not start or stop a trading process instance directly. Instead, you start or stop the corresponding task.

Backtesting Session

A backtesting session is a trading mode by which the trading bot instance reads historic market data in a user-defined datetime range, applies the rules defined in the associated trading system, and generates a trading simulation.

A backtesting session node must reference a trading system to gain access to the trading logic to be applied during the session. Other considerations framing the session come from the set of parameters attached to it.

Adding a Backtesting Session Node

To add a backtesting session, select Add Backtesting Session on the trading process instance node menu. When a session is added, it is created with the full set of parameters.

Configuring the Backtesting Session

Select Configure Session on the menu to access the configuration.

{
"folderName": "Session-Name"
}
  • folderName allows you to set a significant name to the folder in which the data products—and logs—generated by the session are stored. If left blank, the system names the folders with the session id. This may be handy when you intend to consult the raw data generated by the session, as, otherwise, the folder would be hard to identify.

Starting a Backtesting Session

Before you start a backtesting session, the corresponding task needs to be running, as it is the task that puts the trading bot instance to run. Once the trading bot instance is running, select Run on the menu to start the session.

After a few seconds, a literal indication of the progress of the calculations appears below the session node, displaying the date that is currently being processed. Once the calculation is finished, the session stops and the date below the session node dissapears.

To stop a backtesting session, select Stop on the menu.

Paper Trading Session

A paper trading session is a trading mode by which the trading bot instance reads a live market data feed, applies the rules defined in the associated trading system, and generates a trading simulation.

A paper trading session node must reference a trading system to gain access to the trading logic to be applied during the session. Other considerations framing the session come from the set of parameters attached to it.

Adding a Paper Trading Session Node

To add a paper trading session, select Add Paper Trading Session on the trading process instance node menu. When a session is added, it is created with the full set of parameters.

Configuring the Paper Trading Session

Select Configure Session on the menu to access the configuration.

{
"folderName": "Session-Name"
}
  • folderName allows you to set a significant name to the folder in which the data products—and logs—generated by the session are stored. If left blank, the system names the folders with the session id. This may be handy when you intend to consult the raw data generated by the session, as, otherwise, the folder would be hard to identify.

Starting a Paper Trading Session

Before you start a paper trading session, the corresponding task needs to be running, as it is the task that puts the trading bot instance to run. Once the trading bot instance is running, select Run on the menu to start the session.

To stop a backtesting session, select Stop on the menu.

Production Environment

The production environment node organizes trading sessions involving live trading.

Superalgos aims to provide a flexible and robust trading bots deployment toolbox.

With Superalgos, you may deploy as many trading bots as you wish and have them running on a single computer or in as many machines as you wish, in a trading farm type of setup. To help with the management of large numbers of live trading sessions, the system helps you with sorting tasks by exchange, market, and trading mine.

The production environment works pretty much in the same way as the testing environment, save for two important differences:

  • The production environment runs forward testing and live trading sessions, instead of backtesting and paper trading sessions.

  • These two types of sessions involve monetary transactions at the exchange, thus require the set up of a key reference to authenticate your account with the exchange.

Forward Testing Session

A forward testing session is a trading mode by which the trading bot instance performs live trading with a user-defined fraction of the available capital.

A forward testing session node must reference a trading system to gain access to the trading logic to be applied during the session. Other considerations framing the session come from the set of parameters attached to it.

Adding a Forward Testing Session Node

To add a forward testing session, select Add Forward Testing Session on the trading process instance node menu. When a session is added, it is created with the full set of parameters.

Configuring the Forward Testing Session

Select Configure Session on the menu to access the configuration.

{ 
"folderName": "Session-Name",
"balancePercentage": 1
}
  • folderName allows you to set a significant name to the folder in which the data products—and logs—generated by the session are stored. If left blank, the system names the folders with the session id. This may be handy when you intend to consult the raw data generated by the session, as, otherwise, the folder would be hard to identify.

  • balancePercentage is a number defining the percentage of the initialBalance specified in the base aset configuration that will be used for trading. For instance, "balancePercentage": 1 means that 1% of your balance will be made available. Just like the initialBalance is scaled down, the minimumBalance and maximumBalance are also scaled down accordingly (see base asset).

Let’s draw a quick example:

Your base asset is USDT and your initialBalance is USDT 10,000.

If you set up your forward-testing session with “balancePercentage”: “1”, then USDT 10,000 * 1% = USDT 100. This is the balance that will be available to your forward-testing session.

Starting a Forward Testing Session

Before you start a forward testing session, the corresponding task needs to be running, as it is the task that puts the trading bot instance to run. Once the trading bot instance is running, select Run on the menu to start the session.

To stop a backtesting session, select Stop on the menu.

Live Trading Session

A live trading session is a trading mode by which the trading bot instance reads a live market data feed, applies the rules as defined in the associated trading system, places the corresponding orders at the associated exchange, and stores the defined data products.

A live trading session node must reference a trading system to gain access to the trading logic to be applied during the session. Other considerations framing the session come from the set of parameters attached to it.

Adding a Live Trading Session Node

To add a live trading session, select Add Live Trading Session on the trading process instance node menu. When a session is added, it is created with the full set of parameters.

Configuring the Live Trading Session

Select Configure Session on the menu to access the configuration.

{
"folderName": "Session-Name"
}
  • folderName allows you to set a significant name to the folder in which the data products—and logs—generated by the session are stored. If left blank, the system names the folders with the session id. This may be handy when you intend to consult the raw data generated by the session, as, otherwise, the folder would be hard to identify.

Starting a Live Trading Session

Before you start a live trading session, the corresponding task needs to be running, as it is the task that puts the trading bot instance to run. Once the trading bot instance is running, select Run on the menu to start the session.

To stop a backtesting session, select Stop on the menu.

Trading System Reference

A trading engine reference determines which trading system shall be evaluated by the trading bot to run the trading session.

In other words, the trading system reference lets the process instance know which trading rules to process for the given session.

Adding a Trading System Reference Node

To add a trading ensystemgine reference, select Add Missing Children on the trading session node menu.

Trading Engine Reference

A trading engine reference determines which trading engine the trading bot shall use to structure the data it processes while running the trading session.

In other words, the trading engine reference lets the process instance know which data structure to use to store information related to the trading session. This means that a workspace may have more than one trading engine.

Adding a Trading Engine Reference Node

To add a trading engine reference, select Add Missing Children on the trading session node menu.

Parameters

Parameters are properties of trading sessions, defined by users, to determine their behavior and improve the quality of simulations.

The behavior of parameters may vary depending on the type of session.

Each testing session has its own set of parameters. This allows you to configure different trading sessions with different parameters, and go back and forth between them as required. For instance, you may have different backtesting sessions with different date ranges, different exchange fees or different slippage settings to account for different possible scenarios.

Adding a Parameters Node

To add a parameters node, select Add Parameters on the session or the trading system menu, depending on the context. When a parameters node is added, the full set of parameters are created with it.

If you already have a parameters node but are missing some of the parameters, then select Add Missing Params on the menu.

Session Base Asset

The base asset is the asset whose price is determined by the market. It is usually the first asset in the pair, as listed by the exchange.

Among other things, the parameter allows defining an initial balance of the corresponding asset, which may be used for trading with the corresponding trading system and trading session. Please see the configuration.

Adding a Session Base Asset Node

To add a parameter that may be missing, select Add Missing Params on the parameters node menu.

Configuring the Session Base Asset

Select Configure Base Asset on the menu to access the configuration.

{
"initialBalance": 0.001,
"minimumBalance": 0.0001,
"maximumBalance": 0.1
}
  • initialBalance is the amount of capital you wish to allocate to the trading system.

  • minimumBalance is the threshold of accummulated losses that switches off the session; when your overall balance (balanceAssetA + balanceAssetB) drops to this value, all trading stops; think of the minimumBalance as a general safety switch.

  • maximumBalance is a similar concept as with the minimumBalance but on the high side of the initialBalance.

Session Quoted Asset

The quoted asset is the asset on which the price of the base asset is denominated in the market. It is usually the second asset in the pair, as listed by the exchange.

The parameter allows defining an initial balance of the corresponding asset, which may be used for trading with the corresponding trading system and trading session. Please see the configuration.

Adding a Session Quoted Asset Node

To add a parameter that may be missing, select Add Missing Params on the parameters node menu.

Time Frame

The time frame determines the collection of candles to be analyzed during a backtesting session, and the frequency with which the trading bot runs on paper trading, forward testing, and live trading sessions.

In the context of backtesting sessions, what time frame you decide to run the session depends on the trading system being tested. If the trading system makes decisions based on the 1-hour candle and above, then 01-hs may be the best choice. However, if decisions are influenced by sub-hour candles then you should match the time frame accordingly.

In other words, in backtesting sessions, you should match the time frame to the smallest period on which the trading system makes decisions.

In the context of live sessions, that is, paper trading, forward testing, and live trading, you should run the session on the 01-min time frame so that the trading bot reacts fast when the price tags the take profit or stop loss targets. Remember that stop and take profit orders are not placed at the exchange after the take position event, that is, once you enter the position. Instead, the trading bot checks the current price upon each execution cycle and determines whether targets have been hit or not. If targets are hit, only then orders are placed. That is why running live trading sessions at the 01-min time frame is recommended. Learn more about the management of take profit and stop loss targets.

If for whatever reason you don’t need to minimize the potential for slippage when hitting stop or take profit targets, you may choose whatever time frame you like, taking into account the explanations below.

Why the Time Frame Matters

Running trading sessions of any given trading system on different time frames may produce different results. This is because the behavior of a trading session may vary depending on how well the time frame on which the session is run matches the logic of the strategy.

This is why:

The trading bot evaluates closed candles only. At any given point in time, the current candle in each time frame is the candle that closed last.

For example:

Let’s say it’s 2020-06-11T11:39:30:00.000Z, that is, 11 hours, 39 minutes and 30 seconds of June 11th, 2020.

  • The current 1-minute candle is the one which closed at 11:38:59.999.
  • The current 5-minute candle is the one which closed at 11:34:59.999.
  • The current 30-minute candle is the one which closed at 11:29:59.999.
  • The current 1-hour candle is the one which closed at 10:59:59.999.
  • The current 2-hour candle is the one which closed at 09:59:59.999.
  • The current 6-hour candle is the one which closed at 05:59:59.999.
  • The current 24-hour candle is the one which closed at 23:59:59.999 of June 10th!

… and so on.

Let’s say the trading system implements conditions that evaluate 30-minute and 1-hour candles.

If a session is run at the 30-minutes time frame, all 30-minutes candles are evaluated. Also, all 1-hour candles are evaluated twice.

However, if the session is run at the 1-hour time frame, only one out of two 30-minute candles are evaluated.

And if the session is run at the 2-hour time frame, only one out of four 30-minute candles and one out of two 1-hour candles are evaluated.

This means that running the session (for this particular trading system) at the 30-minute time frame has higher probabilities of conditions evaluating 30-minute candles to be true during the session.

In other words, when running the session on time frames higher than the time frame on which decisions are made, chances are the bot will eventually skip candles on which conditions would have evaluated true, potentially skipping trading opportunities.

The above is true for all types of trading sessions.

Backtesting Vs. Live Sessions

In a backtesting session, the collection of candles evaluated is determined by the time frame selected to better simulate what would happen if the live trading session was run in the same time frame.

Adding a Time Frame Node

To add a parameter that may be missing, select Add Missing Params on the parameters node menu.

Configuring the Time Frame

Select Configure Time Frame on the menu to access the configuration.

{
"value": "01-min"
}
  • value is the setting for the time frame. You may use any of the values below.

Available options at the sub-hour level are:

01-min
02-min
03-min
04-min
05-min
10-min
15-min
20-min
30-min
45-min

Available options at larger time frames are:

01-hs
02-hs
03-hs
04-hs
06-hs
08-hs
12-hs
24-hs

Time Range

The time range parameter determines the period of time on which the trading session is run.

The parameter offers precise control over the duration, starting and ending points of the session. Several options are available, and there are differences in how backtesting and the rest of the types of trading sessions function in this regard.

Check the configuration to learn more.

Adding a Time Range Node

To add a parameter that may be missing, select Add Missing Params on the parameters node menu.

Configuring the Time Range

Select Configure Time Range on the menu to access the configuration. The configuration varies slightly depending on the type of session you are running.

On Backtesting Sessions

{
"initialDatetime": "2019-09-01T00:00:00.000Z",
"finalDatetime": "2019-09-25T00:00:00.000Z"
}
  • initialDatetime is the datetime the session starts at.

  • finalDatetime is the datetime the session finishes at. If you don’t set a finalDatetime, the session runs until the date data is available.

On Paper Trading, Forward Testing and Live Trading Sessions

{
"initialDatetime": "2019-09-01T00:00:00.000Z",
"finalDatetime": "2019-09-25T00:00:00.000Z",
"allowStartingFromThePast": false
}
  • finalDatetime is the datetime the session finishes at. If you don’t set a finalDatetime at the level of the testing session or the trading system, then the session runs for one year.

By default, paper trading, forward testing and live trading sessions start at the datetime the session is run, that is, the present time. Such a behavior is in accordance with the most common use case, by which a user starting a new live trading session usually wishes the session to start at that moment.

However, users have requested to be allowed to start live sessions in the past. Such a feature may be useful, for example, to take an opportunity that was just missed for whatever reason, including technical ones.

  • initialDatetime, in combination with the allowStartingFromThePast parameter, is a hack to allow a live session to start from a date in the past. If there is a valid initialDatetime and allowStartingFromThePast is true, then the live session effectively starts from the specified date in the past. If allowStartingFromThePast is false the initialDatetime is ignored and the session starts from the present time.

  • allowStartingFromThePast may be true or false.

Slippage

The slippage is an assumption on the difference between the simulated rate and the actual fill rate of a market order, most relevant in the context of backtesting and paper-trading sessions. The parameter is a tool to make simulations more realistic.

In the context of forward testing and live trading sessions, slippage does not affect the actual transactions. However, the parameter is taken into account when creating the live trading simulation until the actual order fill values are obtained from the exchange.

Adding a Slippage Node

To add a parameter that may be missing, select Add Missing Params on the parameters node menu.

Configuring the Slippage

Select Configure on the menu to access the configuration.

{
"positionRate": 0.1,
"stopLoss": 0.2,
"takeProfit": 0.3
}
  • positionRate is the slippage value applied to the rate of all market orders throughout the position, expressed as a percentage (i.e.: 0.1 means 0.1%).

  • stopLoss is the slippage value applied to the stop loss target defined by the formulas of each stop loss phase in the manage stage of the trading system, expressed as a percentage (i.e.: 0.2 means 0.2%). The slippage value is applied to the value resulting from the corresponding stop loss formula, and the actual stop loss target is the resulting number. For example, if the stop loss formula results in 1000 and the stopLoss slippage value is 0.2, then the resulting stop loss target is 1000 ± 1000 * 0.2 / 100. Read below for an explanation on when the slippage is added or subtracted.

  • takeProfit works similarly as the stopLoss setting, but affecting the take profit target instead of the stop loss target.

The number you enter is applied as a percentage of the rate (of market orders in the case of positionRate and stop loss and take profit targets in the latter cases) and added to or subtracted from the price depending on the circumstances, always working against you. For instance, "positionRate": 0.1 means that market orders will be set at a rate 0.1% worse than ideally.

Slippage is added or subtracted depending on how you define your trading system, but the application is automatic, so you do not need to know every detail. However, if you do wish to understand the details, you need to learn about how the open and close stages are defined in term of the initial targets, along with stop loss and take profit targets in the manage stage. Read about the Open Stage Initial Targets

Fee Structure

The fee structure is a parameter fundamental to the calculation of fees, both in testing and live trading sessions.

Exchange fees are a crucial part of trading. A strategy may work like a charm when you leave fees out of the equation but would lead you to bankruptcy in a live trading situation.

Exchanges don’t usually report the amount charged in fees on each transaction, thus, the system calculates fees and subtract them from balances. Learn more about the handling of fees.

To illustrate how fees affect your bottom line, take a look at the image below.

Trading-Simulation-Fees-Fails

The trade hits the take profit target above the Position Rate level, however, due to fees, the trade has a negative 0.32% ROI.

Adding a Fee Structure Node

To add a parameter that may be missing, select Add Missing Params on the parameters node menu.

Configuring the Fee Structure

Select Configure Fee Structure on the menu to access the configuration.

{
"maker": 0.15,
"taker": 0.25
}
  • maker is the setting for the fee the exchange charges when an order adds liquidity to the market, such as with limit orders.

  • taker is the setting for the fee the exchange charges when an order takes liquidity from the market, such as with market or instant orders.

Snapshots

Snapshots are CSV files output by the trading bot listing every trade in a backtesting session. The snapshots parameter determines whether snapshots shall be produced, and how.

Learn more about snapshots and check the configuration file to control if and how snapshots are produced.

Adding a Snapshots Node

To add a parameter that may be missing, select Add Missing Params on the parameters node menu.

Configuring the Snapshots

Select Configure Slippage on the menu to access the configuration.

{ 
   "strategy": true,
   "position": true
}
  • strategy determines whether to take a snapshot at the trigger on event or not; possible values are true or false.

  • position determines whether to take a snapshot at the take position event or not; possible values are true or false.

Heartbeats

During a trading session, the backend communicates with the frontend via heartbeats to inform the frontend about the status of the session. The parameter controls what information is made available to the user through the frontend.

This parameter affects how you see the progress of the trading session below the trading bot instance node on the design space.

Adding a Heartbeats Node

To add a parameter that may be missing, select Add Missing Params on the parameters node menu.

Configuring the Heartbeats

Select Configure Slippage on the menu to access the configuration.

{ 
   "date": true,
   "candleIndex": false
}
  • date determines whether the date is shown in the progress notice below the trading process instance node; possible values are true or false.

  • candleIndex determines whether the index of the candle is shown in the progress notice below the trading process instance node; possible values are true or false.

User Defined Parameters

Users may define parameters to be used within the trading system during the trading session.

Parameters defined in the configuration file of these node become available to trading systems using the following path: sessionParameters.userDefinedParameters.config.parameterName.

These parameters may be useful, for example, when you wish to use a constant multiple times across several nodes in the definition of a strategy. Instead of feeding a constant value to all formulas involved, you may feed the parameter instead. This gives you the added benefit of being able to change the value of such a constant in a single point.

Adding a User Defined Parameters Node

To add a parameter that may be missing, select Add Missing Params on the parameters node menu.

Configuring the User Defined Parameters

Select Configure Slippage on the menu to access the configuration.

{ 
   "param1Name": "A text string value example",
   "param2Name": 0
}
  • param1Name is an example of a name. You may change the names of the parameters as required. Values including text strings go between quotation marks, while numeric values, without. You may define as many parameters as you wish; simply separate them with a comma to keep a valid JSON format for the configuration file.

Data Storage

The data storage node holds the definitions as to what data is stored in the corresponding network node.

Bot instances running on the data mining and trading sections of a network node produce data products that need to be stored somewhere, specifically. The data storage node and its chain of offspring determine which data is to be stored where; that is, in what network node.

Like with the data mining section and the sections referring to trading operations (testing and production environments), the data storage section is too organized by exchange, market, and data or trading mines. See the sorting of tasks page for the details.

The storage of data is split between data mines data and trading mines data. This is to facilitate the management of data storage definitions in trading farms, on which data mining operations may be separate from trading operations.

The data stored on each node of the network may be accessed by others, including the charting system, to visualize information via plotters defined in data mines, by trading systems to make trading decisions, and even by third-party systems. The information regarding trading mine data is explained in length in the trading engine section of the documentation.

The setup of data storage definitions is done automatically when the install market function under the exchange markets node of the Crypto Ecosystem hierarchy is used. However, when data mining or trading tasks are created manually, the data storage definitions must be created manually as well, using the tools available in each of the data structures below this node.

Adding a Data Storage Node

To add a data storage, select Add Data Storage on the network node menu.

Data Mines Data

Session independent data refers to data generated by sensors and indicators, not related to trading sessions.

Adding a Data Mines Data Node

To add a session-independent data node, select Add Session-independent Data on the network node menu.

Exchange Data Products

The exchange data products node organizes data mines data by exchange. That is, each exchange installed in the system has an exchange data products node grouping all market data products nodes corresponding to the said exchange.

The exchange data products node must reference the exchange of choice. This reference constraints the rest of the definitions to the context of the said exchange.

When representing an exchange featured in the system’s icons library, the standard exchange data tasks icon is replaced by the exchange’s logo.

Adding an Exchange Data Products Node

To add a specific exchange data products node, select Add Exchange Data Products on the parent node menu.

You may also add exchange data products nodes in bulk for all exchanges that may have been previously defined in the Crypto Ecosystem hierarchy. To do that, select Add Missing Exchanges on the parent node menu. An exchange data products node is created for each defined exchange, each with the corresponding reference.

Market Data Products

A market data products node represents the group of data products generated in a specific market.

The market data products node must reference a market defined in the Crypto Ecosystem hierarchy.

This node may spawn individual data products or may deploy data products in bulk organized by data mine and by bots. See the data products node for the details.

Adding a Market Data Products Node

To add a market data products node, select Add Market Data on the parent node menu.

You may also add market data products nodes in bulk for all markets that may have been previously defined in the Crypto Ecosystem hierarchy. To do that, select Add Missing Markets on the parent node menu. A market data products node is created for each defined market, each with the corresponding reference.

Data Mine Products

Data mine products are references established with data mines to facilitate establishing data product references with multiple products in the given data mine.

The node may be used as an organizational device, simply to arrange bot products. However, the smart use of the node involves automating the deployment of multiple data products.

The use of the data mine products node is optional, as data products may also exist outside of data mine products nodes.

Adding a Data Mine Products Node

To add a data mine products node, select Add Data Mine Products on the parent node menu. This action adds the node but does not establish a reference with any data mine.

The smarter use of the node involves using the Add All Data Mine Products option on the parent node menu. This action creates a data mine products node for each data mine in the workspace, establishing a reference with the corresponding data mines. This is the first step in the direction of quickly setting up multiple data products when needed.

Bot Products

A bot products node is an organizational device used to arrange data products corresponding to a specific bot.

The device exists as an offspring of a data or trading mine products node, and does not require a reference to a bot in the given data or trading mine.

The use of the bot products node is optional, as data products may also exist outside of bot products.

Adding a Bot Products Node

To add a bot products node, select Add Bot Products on the parent node menu.

The bot products node may also be created automatically. When created using the Add All Data Products option on the data mine products node, the node inherits the label of the corresponding bot in the corresponding data mine.

Data Product Folder

A data product folder node is an organizational device used to map the arrangement of product definition folders as may exist in the bot definition of the corresponding data or trading mine.

The use of the data product folder node is optional, as data products may also exist outside of data product folders.

Adding a Data Product Folder Node

To add the data product folder node, select Add Data Product Folder on the parent node menu.

Data Product

A data product represents the collection of datasets generated by the instance of a bot as defined in the corresponding data mine or trading mine.

Data products exist in the context of trading mines data and data mines data nodes. In the first case, a data product is the collection of datasets generated by an instance of a trading bot as defined in a trading mine, running a trading session. In the latter case, it is the collection of datasets generated by either a sensor bot or an indicator bot instance, as defined in a data mine, and running a data mining task.

A data product node must reference a product definition in the corresponding bot.

Adding a Data Product Node

To add a single data product, select Add Data Product on the market trading products, market data products, bot products, or data products folder node menus.

In cases in which multiple data products must be added, you may use the option to create data products in bulk.

Select the Add All Data Products option on the data or trading mine products node menu. This adds a bot products node for each bot in the data or trading mine, and a data product for each product definition of each bot.

You may use this option after manually adding a data or trading mine products node and manually establishing the reference with the desired data mine, or after adding all data or trading mine data products, by which the references with data or trading mines are established automatically.

Trading Mines Data

Session-based data refers to data that is generated as a consequence of running a trading session, that is, data the trading bot instance generates while running backtesting, paper trading, forward testing, or live trading sessions.

As explained in the sorting of tasks page, trading mines data is sorted by exchange, market, the corresponding trading session, and the corresponding trading mine, trading bot, and bot product. That is, most of the nodes in this section of the hierarchy play an organizational role.

Many of them require references to the nodes that delimit the context for which the data is applicable. For example, the exchange trading products node must reference one of the installed exchanges, in particular, the exchange on which the trading operation is run. These references help other entities understand the context to which the data belongs to.

Whenever you create trading tasks manually from within the Network hierarchy (as opposed to using the install market function under the exchange markets node of the Crypto Ecosystem hierarchy), you need to create the proper definitions for the storage of trading mines data.

Adding a Trading Mines Data Node

To add a session-based data node, select Add Session-based Data on the network node menu.

Exchange Trading Products

The exchange trading products node organizes trading mines data by exchange. That is, each exchange installed in the system has an exchange trading products node grouping all session references corresponding to the said exchange.

The exchange trading products node must reference the exchange of choice. This reference constraints the rest of the definitions to the context of the said exchange.

When representing an exchange featured in the system’s icons library, the standard exchange trading products icon is replaced by the exchange’s logo.

Adding an Exchange Trading Products Node

To add a specific exchange trading products node, select Add Exchange Trading Products on the parent node menu.

You may also add exchange trading products nodes in bulk for all exchanges that may have been previously defined in the Crypto Ecosystem hierarchy. To do that, select Add Missing Exchanges on the trading mines data node menu. An exchange trading products node is created for each defined exchange, each with the corresponding reference.

Market Trading Products

A market trading products node features the group of data products generated by the referenced session in a specific market.

The market trading products node must reference a market defined in the Crypto Ecosystem hierarchy.

This node may spawn individual data products or may deploy data products in bulk organized by trading mine and by trading bots. See the data products node for the details.

Adding a Market Trading Products Node

To add a market trading products node, select Add Market Trading Data on the parent node menu.

Session Reference

A session reference establishes which session is the one which shall store data in the current location.

A such, the session reference node must establish a reference with a trading session. Also, its offspring nodes determine precisely which data products are stored.

Adding a Session Reference Node

To add a session reference node, select Add Session Reference on the network node menu.

You may also add session reference nodes in bulk for all sessions defined in the same network that are not yet defined. To do that, select Add Missing Sessions on the exchange trading products node menu. A session reference node is created for each defined trading session in the node, each with the corresponding reference.

Trading Mine Products

Trading mine products are references established with trading mines to facilitate establishing data product references with multiple products in the given mine.

At this point, Superalgos ships with a single trading mine, featuring a single low frequency trading bot. However, developers may create their own trading bots or fork the existing one.

The node may be used as an organizational device, simply to arrange bot products. However, the smart use of the node involves automating the deployment of multiple data products.

The use of the trading mine products node is optional, as data products may also exist outside of trading mine products nodes.

Adding a Trading Mine Products Node

To add a trading mine products node, select Add Trading Mine Products on the parent node menu. This action adds the node but does not establish a reference with any trading mine.

The smarter use of the node involves using the Add All Trading Mine Products option on the parent node menu. This action creates a trading mine products node for each trading mine in the workspace, establishing a reference with the corresponding trading mines. This is the first step in the direction of quickly setting up multiple data products when needed.