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 Storage

Session Based Data

Session Reference

Single Market Data

Data Product

Session Independent Data

Single Market Data

Data Product

Data Mining

Task Manager

Task

Sensor Bot Instance

Sensor Process Instance

Market Reference

Key Instance

Indicator Bot Instance

Indicator Process Instance

Market Reference

Testing Environment

Task Manager

Task

Trading Bot Instance

Trading Process Instance

Market Reference

Backtesting Session

Paper Trading Session

Parameters

Base Asset

Quoted Asset

Time Range

Time Frame

Slippage

Fee Structure

Production Environment

Task Manager

Task

Trading Bot Instance

Trading Process Instance

Market Reference

Key Instance

Forward Testing Session

Live Trading Session

Parameters

Base Asset

Quoted Asset

Time Range

Time Frame

Slippage

Fee Structure

Network

The network hierarchy contains definitions regarding the physical location in which certain nodes live or function. For instance, a certain process my run and store data in your local machine or some other machine in the network.

You will use the network hierarchy for the following purposes:

  • To control your data mining—that is, processes running sensor and indicator bots. These keep your data feeds up to date so that you may trade live with quality information.

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

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

  • To control your data storage—that is, to administer the physical location in which the data products produced by bots reside.

Network Node

A network node represents a machine running Superalgos, on which processes run or 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.

You may create unlimited network nodes and map them with different machines on a network. Each machine in the network runs an instance of Superalgos. However, you may control the whole network operation from a single machine, or—in general—from any machine in the network.

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": "34247", 
"webSocketsPort": "8080"
}
  • 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 34247.

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

Data Mining

Data mining is the activity of processing data. You need to process data to feed charts, and so that the trading bot may make decisions based on quality information. In the context of the network hierarchy, the data-mining node groups the task managers handling sensor and indicator bots instances.

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.

Exchange Tasks

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

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

Adding an Exchange Tasks Node

Exchange tasks nodes are added automatically when the first market in the corresponding exchange is installed. To manually add an exchange tasks node, select Add Exchange Tasks on the data mining, testing environment or production environment nodes.

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.

A task manager facilitates the organization of tasks. For example, you may wish to set up a task manager to handle tasks related to a particular set of indicators you use 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 My Computer network node menu. A task manager is added along with a task.

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. When a sensor bot instance is added, it is created with one sensor process instance, and a market reference.

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 Charly sensor bot, the sensor bot process instance references the Historic Trades 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. When a sensor process instance is added, it is created with a market reference.

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. When an indicator bot instance is added, it is created with one indicator process instance, and a market reference.

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. When an indicator process instance is added, it is created with a market reference.

Starting an Indicator Process Instance

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

Market Reference

A market reference is a reference to a specific market in a specific exchange, as defined in the Crypto Ecosystem hierarchy. The reference dictates which market the process works with.

In other words, a market reference is the piece of information that lets the process instance know which market of which exchange it needs to process.

Adding a Market Reference Node

To add a market reference, select Add Market Reference on the sensor, indicator or trading process instance node menu.

Key Instance

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

The key instance must be attached to market reference nodes that participate in forward testing and live trading sessions, as that is the scenario in which the user must validate the account with the exchange.

Some exchanges—like Binance—require validating the user even when retrieving data from the exchange. For such reasons, the key instance must also be attached to the market reference of the sensor process instance that connects to such exchanges.

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

Adding a Key Instance Node

To add a key instance, select Add Key Instance on the market reference node menu.

Testing Environment

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

A 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. It is recommended you organize all of your testing sessions below the testing environment 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 strategy-deployment toolbox.

If you work with multiple markets, multiple exchanges, or multiple trading systems, it is recommended to organize your forward testing and live trading sessions below the production environment node.

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 Live Session Requirements 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 Live Session Requirements

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 Live Session Requirements

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 Session Requirements 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 Session Requirements

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 Session Requirements

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.

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.

Base Asset

In the context of trading sessions, the base asset is the asset in the pair on which capital stands when out of a trade. In other words, it is the asset you wish to accumulate.

The base asset must reference an exchange account asset under exchange accountsuser account of the corresponding crypto exchange in the Crypto Ecosystem hierarchy.

The exchange account asset referenced must be one of the assets in the pair of the specific market and the specific crypto exchange that the trading session is associated with.

Adding a Base Asset Node

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

Configuring the 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.

Quoted Asset

In the context of trading sessions, the quoted asset is the asset in the pair for which capital is exchanged at the take position event, and which is traded back for the base asset when closing the trade.

The quoted asset must reference an exchange account asset under exchange accountsuser account of the corresponding crypto exchange in the Crypto Ecosystem hierarchy.

The exchange account asset referenced must be one of the assets in the pair of the specific market and the specific crypto exchange that the trading session is associated with.

Adding a 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 is the frequency on which the session runs, meaning that the associated process instance runs once per unit of the time frame.

In the context of backtesting sessions, what time frame you decide to run the session on depends on the strategies being tested. If strategies make 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 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.

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 is the specific period between a starting and an ending date on which the session runs.

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. If you don’t set an initialDatetime the system’s fallback mechanism will try to get it from the parameters defined at the level of the trading system.

  • 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 calculations will run until the date there is data available.

On Paper Trading, Forward Testing and Live Trading Sessions

These sessions always start at the datetime the session is run, therefore, there is no configuration of an initial datetime.

{
"finalDatetime": "2019-09-25T00:00:00.000Z"
}
  • 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.

Slippage

The slippage is an assumption on the difference between the simulated rate and the actual fill rate of an 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 simulation layers, which are also available during forward testing and live trading.

Slippage is factored both in the session reports and in the graphic representation of each trade provided by the simulation trades product of the trading bot.

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 Slippage on the menu to access the configuration.

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

  • stopLoss is the slippage value to be applied to the rate of the stop order, expressed as a percentage (i.e.: 0.2 means 0.2%).

  • takeProfit is the slippage value to be applied to the rate of the take profit order, expressed as a percentage (i.e.: 0.3 means 0.3%).

The number you enter is applied as a percentage of the price of the order and added or subtracted from the price depending on the circumstances, always working against you. For instance, "positionRate": 0.1 means the position will be set at a price 0.1% higher or lower depending on which of the assets in the pair is your base asset.

Fee Structure

The fee structure is a parameter enabling users to enter assumptions on fees, to be computed on backtesting and paper trading sessions to make simulations more realistic.

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.

Fee structures are factored both in the session reports and in the graphic representation of each trade provided by the simulation trades product of the trading bot.

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.

In the context of forward testing and live trading sessions, the fee structure assumptions do not affect actual transactions. However, the parameter is taken into account when creating simulation layers, which are also available during forward testing and live trading.

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.

Data Storage

The data storage node controls aspects of what data is to be stored in the corresponding network node.

Data products generated by the bot instances you run need to be stored somewhere—specifically. The data storage node and its chain of offspring determine that the data is to be stored in the corresponding node.

Adding a Data Storage Node

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

Session Based Data

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

Adding a Session Based Data Node

To add a session-based data node, select Add Session-based Data on the network 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 session. In addition, 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.

Single Market Data

Single market data represents the group of data products generated by the referenced session, in a specific market.

The single market data node must establish a reference with a specific market defined in the Crypto Ecosystem hierarchy.

Adding a Single Market Data Node

To add a single market data node, select Add Single Market Data on the network 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.

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

Adding a Data Product Node

To add a data product, select Add Data Product on the network node menu.

Session Independent Data

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

Adding a Session Independent Data Node

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