A trading system provides the tools to build, test and depoy trading strategies from within a visual environment, with no coding requirements.

Trading System

Strategy

Trigger Stage

Trigger-On Event

Situation

Condition

Trigger-Off Event

Situation

Condition

Take Position Event

Situation

Condition

Open Stage

Initial Targets

Target Rate

Formula

Target Size In Base Asset

Formula

Target Size In Quoted Asset

Formula

Open Execution

Execution Algorithm

Market Buy Order

Create Order Event

Situation

Condition

Simulated Exchange Events

Simulated Partial Fill

Simulated Actual Rate

Formula

Simulated Fees Paid

Market Sell Order

Limit Buy Order

Order Rate

Formula

Create Order Event

Cancel Order Event

Simulated Exchange Events

Limit Sell Order

Close Stage Event

Situation

Condition

Manage Stage

Managed Stop Loss

Phase

Formula

Next Phase Event

Situation

Condition

Move to Phase Event

Situation

Condition

Managed Take Profit

Phase

Formula

Next Phase Event

Situation

Condition

Move to Phase Event

Situation

Condition

Close Stage

Initial Targets

Target Rate

Formula

Target Size In Base Asset

Formula

Target Size In Quoted Asset

Formula

Open Execution

Execution Algorithm

Market Buy Order

Create Order Event

Situation

Condition

Simulated Exchange Events

Simulated Partial Fill

Simulated Actual Rate

Formula

Simulated Fees Paid

Market Sell Order

Limit Buy Order

Order Rate

Formula

Create Order Event

Simulated Exchange Events

Close Stage Event

Situation

Condition

Trading System

A trading system is a framework handling the low-level logic that serves to structure the processes and methods used to implement and deploy trading strategies.

In practical terms, a trading system is a hierarchical arrangement organizing the actionable aspects of your investment plan. The hierarchy contains definitions regarding any number of trading strategies, all operating on the same market and sharing the same initial capital allocation.

You use a trading system to define strategies following the Superalgos Protocol, splitting strategies into four stages: trigger, open, manage, and close.

The concept of describing strategies in stages is fundamental to the methodical aspect of the trading system, as it provides a framework to run every strategy with the same framework, which contributes to developing scalable trading systems that may grow to any number of strategies.

When a trading system features more than one strategy, the first strategy has precedence over the second, the second over the third, and so on. This means that strategies are evaluated in a sequence. When a given strategy is triggered-on, the remaining strategies in the queue are no longer evaluated until the strategy triggers off. In other words, when multiple strategies are deployed within a single trading system, only one strategy may trade at any given moment, and precedence is given by the order around the trading system node.

As a corollary to the above, if you wish strategies to operate in different markets, or you wish strategies to be able to take positions simultaneously, then you must set up those strategies in different trading systems.

Adding a Trading System Node

To add a trading system, select Add Trading System on the other hierarchies node menu in the Superalgos Project hierarchy.

Strategy

A trading strategy is the description of a set of actions or events run in stages. Events are triggered upon the validation of precise conditions describing specific market situations. Trading strategies are designed to achieve a specific goal within the broader plan of a trading system via taking and managing positions.

The definition of a strategy may be analyzed in three sections:

A strategy is a set of actions occurring in stages

Strategies are defined in the following stages:

These stages are played in a sequence: once a strategy is triggered it looks to open a position; once a position is open, it is time to manage it as the trade develops; and once a stop or take profit target is hit, it is time to close the position.

While stages are played in a sequence, upon execution there are overlaps. That is, a stage doesn’t need to be closed for the next stage to be opened. The framework sets a clear separation of the concepts embodied in each stage to facilitate the process of defining and developing a trading system. But the truth is that, both at the conceptual level and during execution, the lines between stages are rather blurry.

designed to achieve a specific goal within a broader plan

Your investment plan or trading career may have any number of goals (e.g.: accumulating a certain asset, diversifying on a basket of coins, annual profit targets, etc.). If you attempt to achieve more than one goal with a single strategy, you will sooner or later run into problems. It may be doable, but the strategy would certainly be more complex than is necessary or desirable. In any case, the logical thing to do is to analyze each goal separately so that you may design (at least) one clear, straightforward strategy for each goal.

One of the edges granted by trading automation is the capacity to develop and deploy an unlimited number of strategies. At the same time, Superalgos allows the administration of complexity by breaking down and structuring concepts in small units: a trading system contains strategies, which contain stages, which contain specific definitions.

Understanding that keeping things simple is important will help you develop a robust and extensible arsenal of bots. Simplicity is the key to sustainability.

In other words, the infrastructure provided by Superalgos enables the hyperspecialization of strategies. Do not aim to trade in all sorts of market situations with the same strategy. Instead, develop a strategy for each market situation you wish to trade.

via taking and managing positions

The definition of strategy points to the concept of a position. A position is a process that exchanges the base asset for the quoted asset and that—after some time, as the position develops and targets are hit—exchanges back the quoted asset for the base asset.

The framework implemented in the Superalgos Protocol is optimized to work with such a concept.

However, Superalgos is flexible enough to allow you to override this hard interpretation of the concept of a position. For example, you may design market-making strategies, a strategy to balance portfolios, or develop all sorts of ideas that don’t necessarily fit in that part of the definition.

Adding a Strategy Node

To add a strategy, select Add Strategy on the trading system node menu. The strategy node is created along with the rest of the basic structure of nodes required to define each of the strategy stages and their events.

Trigger Stage

The trigger stage deals with monitoring the market in search of trading opportunities with the corresponding strategy.

A trading system may have multiple strategies designed for the same market.

An important aspect of trading systems is that they are allocated a certain amount of capital (see the base asset parameter of the trading session). As a consequence, strategies within a trading system share a certain capital allocation.

The logic behind the concept of the trigger stage assumes that different strategies within a trading system may be specialized for trading in different market situations. The trigger stage in each strategy is, therefore, the mechanism by which any particular strategy within the trading system may be selected to trade, given any particular market situation.

The triggering-on of a strategy effectively blocks the selection of any other strategy in the trading system and reserves the whole capital allocation for the one strategy selected, until the strategy is triggered-off.

Therefore, if certain strategies are meant to trade under the same market situations and open trades concurrently, then those strategies should be deployed in separate trading systems.

Once a strategy is triggered, the strategy may decide—or not—to take a position. If a position is taken, then the rest of the stages eventually become active.

However, the strategy may also be triggered off without taking a position. When a strategy is triggered off, the trading system goes back to monitoring the trigger-on definitions for all strategies, and capital is released to be used by whatever strategy is triggered-on next.

Adding a Trigger Stage Node

To add a trigger stage node, select Add Missing Stages on the strategy node menu. All stages that may be missing are created along with the rest of the basic structure of nodes required to define each of them and their events.

Trigger-On Event

The trigger-on event defines the set of rules that need to be met for the corresponding strategy to be triggered on. A strategy that is triggered may use all the capital available to the trading system, and prevents other strategies in the system from triggering.

In conceptual terms, the trigger-on event is the mechanism you use to define the specific situations in which you would consider trading with the corresponding strategy. Think of the trigger-on event as the definition of the scenario in which the trading idea behind the strategy should be carefully considered.

Once a strategy is triggered-on, the system starts evaluating the take position event. In conceptual terms, it means that the system has been alerted that the trading idea behind the corresponding trading strategy has produced a signal and that it should carefully monitor the market for the opportunity to take a position.

Adding the Trigger-On Event Node

To add a trigger-on event node, select Add Missing Events on the trigger stage node menu. All events that may be missing are created along with the rest of the basic structure of nodes required to define each of them.

Situation

A situation refers to a specific state of the market in which a certain event should take place, as defined by any number of conditions.

In other words, you define situations in which you wish a certain event to happen (i.e.: trigger on the strategy, take a position, etc.) and each situation is described as a set of conditions that need to be met for the event to be triggered.

A situation gets validated when all conditions under it are true.

An event may have more than one situation attached to it. In such a case, when any of the situations gets validated, the event gets triggered. That is, events may be triggered in different circumstances, meaning that you are free to define different situations upon which the same event would be triggered. In such a case, when any of the situations evaluate true, then the event is triggered.

Adding a Situation Node

To add a situation, select Add Situation on the corresponding event node menu. A situation is added along with a condition and JavaScript code node.

Condition

Conditions are rules within a situation. When all conditions under a situation validate true, then the situation gets validated as well, and the associated event is triggered.

Therefore, conditions are used to mathematically describe what needs to happen with the market for a certain action to be taken.

For example:

Situation 1

  • Condition A: chart.at01hs.candle.close > chart.at01hs.bollingerBand.MovingAverage → This means that the latest candle at the 1 hour chart closed above the Bollinger Bands moving average.

  • Condition B: chart.at01hs.candle.previous.max > chart.at01hs.bollingerBand.previous.MovingAverage → This means that the maximum value of the candle before the last one, was higher than the Bollinger Bands moving average.

In the example above, conditions A and B are comparison statements that may evaluate either true or false. In the case both would evaluate true then Situation 1 would be true as well.

Adding a Condition Node

To add a condition, select Add Condition on the corresponding situation node menu. A condition with its JavaScript code node is added.

Trigger-Off Event

The trigger-off event defines the situation in which the corresponding strategy shall be triggered-off. A strategy that is triggered-off releases the capital in reserve and makes it available to other strategies in the trading system.

In conceptual terms, the trigger-off event is the mechanism you use to define the situation in which the corresponding strategy should stop considering the trading opportunity signaled by the trigger-on event. That is, you use the trigger off event to describe the scenario for the invalidation of the trading idea behind the strategy.

Once a strategy is triggered-on, only two possible scenarios may follow. Either the take position event is triggered, thus, taking a position, or the trigger-off event is triggered first.

In the first scenario, the strategy remains on until the position is closed. As the position is closed, the strategy is triggered-off. In the second scenario, the strategy is triggered-off immediately.

Adding the Trigger-Off Event Node

To add a trigger-off event node, select Add Missing Events on the trigger stage node menu. All events that may be missing are created along with the rest of the basic structure of nodes required to define each of them.

Take Position Event

The take position event defines the situation that needs to be met to take a position.

The trigger-on event merely selects a strategy to be considered for trading under the current market situation. The actual decision to enter a position may require more specific conditions to be met. For that reason, the take position event is a separate entity from the trigger-on event.

Therefore, the take position event is defined with its own set of situations and conditions.

Once the take position event is triggered, the decision to take a position has been made and there is nothing else to consider in that regard. Therefore, the runtime evaluation of the trading system shifts from the trigger stage to the open stage.

Adding the Take Position Event Node

To add a take position event node, select Add Missing Events on the trigger stage node menu. All events that may be missing are created along with the rest of the basic structure of nodes required to define each of them.

Open Stage

The open stage deals with the definitions that make up the logic to enter a position, including the target rate and size, and order execution.

The open stage comes into play once the take position event is triggered. Conceptually, the open stage deals with the details concerning how the position shall be opened once the decision to take a position has been made. That is, the open stage does not participate in the process of deciding whether a position should be open or not.

To take a position, several definitions are required. In particular, those concerning targets, such as the rate and size of the position, and the logic of the execution strategy, that is, how many of which orders shall be placed at the exchange—and when—to enter the position.

The open stage closes as soon as one of the following events happen:

  • the target size gets filled,

  • the close stage event is triggered,

  • the take profit or stop loss targets are hit.

Adding the Open Stage Node

To add an open stage node, select Add Missing Stages on the strategy node menu. All stages that may be missing are created along with the rest of the basic structure of nodes required to define each of them and their events.

Initial Targets

The initial targets node holds the most basic definitions about the position to be taken: the target rate and the target size.

Adding an Initial Targets Node

To add the initial targets node, select Add Missing Items on the parent node menu.

Target Rate

The target rate is a reference rate that may affect simulations and that, in combination with the placement of managed stop loss and managed take profit targets, is used to determine whether the targets have been hit.

Internal Use

The system needs to determine when the managed stop loss and managed take profit targets have been hit. To do this, the system observes how the user places the targets in relation to the target rate.

For example:

If the phase 1 managed stop loss target is placed below the target rate and the phase 1 managed take profit target above it, the system assumes that:

  • the stop loss target is hit when the current rate is equal to or smaller than the managed stop loss value;

  • the stop loss target is hit when the current rate is equal to or greater than the managed take profit value;

The reversed example is true, as well.

This is how the system uses the target rate internally.

Fetching the Value from Formulas

Additionally, defining a target rate at the level of the stage may be of use so that you may retrieve the value from formulas while setting the rate of limit orders, using the path of the corresponding node at the trading engine.

For example, tradingEngine.current.position.entryTargetRate.value or tradingEngine.current.position.exitTargetRate.value.

Affecting How Simulations are Plotted

The target rates defined at the open and close stages affect how the Posittion Base Asset and Position Quoted Asset layers in the Simulation Objects layer manager draw the triangle representing the development of the trade.

The Position Base Asset layer is on, providing a visual clue of how the position developed.

The horizontal segment marks the target rate defined at the open stage. If you are using market orders to take the position, then using tradingEngine.current.episode.candle.close.value may offer a good representation of the rate of market orders. If you are using limit orders, then you may decide at which rate you wish to take the position, and the horizontal segment of the triangle will match the chosen rate.

The third vertex of the triangle points to a [datetime, rate] coordinate. The datetime is given by the candle on which the manage stage closes, that is, the candle at which the stop loss or take profit targets are hit. The rate portion of the coordinate is given by the target rate defined in the close stage.

You may choose to apply a similar reasoning as with the open stage target rate for limit orders, but there is some nouance to consider if you are using market orders.

The issue arises if you when you run a testing session at a time frame higher than the time frame you use for live trading.

Why is that an issue?

Let’s say your trading system makes decisions based on the close of the 1-hour candle. And let’s say you are using stop loss and take profit targets. In such cases—when live trading—you may want to run your strategy in the 1-minute time frame, to detect the tagging of the take profit and stop targets as soon as possible, and act accordingly.

However, when backtesting, it is much faster to run sessions on the 1-hour time frame. This is particularly important when you wish to test significant time ranges.

When backtesting a strategy on the 1-hour time frame, the trading bot evaluates if stop loss and take profit targets have been hit at the close of the 1-hour candle, and may only act upon the evaluation on the next candle. This means that if you are using market orders to exit the position, the market order would be placed (in the simulation!) on the candle after one of the targets was hit.

The difference in rate between the moment in time the target is hit and the time the 1-hour candle closes may be significant. As a result, if the close stage target rate is defined as tradingEngine.current.episode.candle.close.value, the resulting simulation may show significant slippage, and diverge from what the trade would look like if running on the 1-minute time frame, like you would when trading live.

To solve the above issue, you may use a more ellaborate formula for the target rate in the close stage:

targetRate()

function targetRate() {
    switch (tradingEngine.current.position.exitType.value) {
        case 'No Exit': {
            return tradingEngine.current.episode.candle.close.value
            break
        }
        case 'Take Profit': {
            return tradingEngine.current.position.takeProfit.finalValue.value
            break
        }
        case 'Stop Loss': {
            return tradingEngine.current.position.stopLoss.finalValue.value
            break
        }
    }
}

This formula discriminates among three possible outcomes:

  • When the no target has been hit, the value of the target rate is the close of the current candle.

  • When the take profit is hit, the value of the target rate is the last value of the take profit.

  • When the stop loss is hit, the value of the target rate is the last value of the stop loss.

In other words, the above formula simulates what would happen when running the trading session on the 1-minute time frame.

Adding a Target Rate Node

To add the target rate node, select Add Missing Items on the parent node menu.

Formula

A formula is a mathematical expression intended to determine a numerical value to be applied dynamically to a certain property.

In the context of a trading system, formulas are used to determine the values for several properties, such as the target rate, target size, managed stop loss, managed take profit, and so on.

Formulas may use indicators and trading engine properties. The main difference between writing a formula and writing a condition is that while conditions must evaluate to true or false, formulas must evaluate to a number.

A simple math example:

This simple formula may be used to define an initial take profit target 3% above the rate at which the position was taken.

tradingEngine.current.position.entryTargetRate.value * 1.03

A simple JavaScript example:

A bit of very basic JavaScript, introducing conditional statements, allows more intelligence. For example, in this case, we ask if the proposed formula results in a number greater than the current stop loss value; if it does, then the proposed formula is used; if not, then the current stop loss value is left as is.

This is—basically—a trailing stop loss 2% below the moving average that may go higher if the moving average goes up, but it may never come down—thanks to the use of the IF ELSE clause.

if (chart.at01hs.bollingerBand.movingAverage * 0.98 > tradingEngine.current.position.stopLoss.value) 
   {chart.at01hs.bollingerBand.movingAverage * 0.98} 
   else 
   {tradingEngine.current.position.stopLoss.value}

For developers:

To build more complex logic within a formula, create a function that implements the logic and returns a numerical value, and then call the function:

function orderRate() {
    const ORDER_STEP_NUMBER = 1    // Secuential step number, starting with 1 from the closest to the price.
    const BUY_SELL_SIGN = -1       // 1 for buy orders, -1 for sell orders.
    const STEP_SEPARATION = 0.15   // % of separation of stair steps between them.
    const BASE_FACTOR = 0.2        // % above or below bollinger band without bias.
    const BIAS_FACTOR = 0.3        // % to move the whole stair of orders up or down depending on the bias.
    const BAND_RATE = chart.at01min.bollingerBand.lowerBand    //  Upper Bollinger Band for sell orders, and Lower for buy orders.

    let inbalance = tradingEngine.current.episode.episodeBaseAsset.beginBalance.value - tradingEngine.current.episode.episodeBaseAsset.balance.value

    let BIAS_SIGN

    if (inbalance === 0) {
        BIAS_SIGN = 0
    }
    if (inbalance < 0) {
        BIAS_SIGN = + 1
    }
    if (inbalance > 0) {
        BIAS_SIGN = - 1
    }

    let rate = BAND_RATE + BUY_SELL_SIGN * BAND_RATE * (BASE_FACTOR + ORDER_STEP_NUMBER * STEP_SEPARATION + BIAS_SIGN * BIAS_FACTOR) / 100

    return rate
}

orderRate()

Adding a Formula Node

To add a formula, select Add Formula on the corresponding parent node menu.

Target Size In Base Asset

Target size in base asset is used to define the size of the position, denominating it in the base asset.

The system supports defining the size of the position in either asset involved in the market: the base asset, or the quoted asset, as per the exchange listing of the market.

The target size may be defined in one of the two assets only, to avoid inconsistencies.

The target size is the maximum size the position may achieve. That is, the definition of the target size is used as a cap for the total size of orders that may be placed during the open stage.

If you prefer to define the size of the position denominated in the base asset, then use this node and delete the target size in quoted asset node.

Even though the definition of the target size is denominated in one of the two assets in the market, the system keeps track of accounts for both assets. That is, performance metrics such as profit loss, ROI, hit ratio, or the annualized rate of return are calculated both based on the base asset and the quoted asset. In fact, metrics are also calculated in a consolidated manner, taking into account both assets at the same time.

All of this information is made available for multiple contexts, for instance, for each position or the whole episode, through the data structure of the trading engine.

When tracking the results of your trading operation, make sure you refer to the set of accounts that make sense for your trading system. This will all become clearer once you read about the trading engine and the layer managers available on the charts.

Examples

If you are trading the whole balance assigned to the trading system on each position, then your target size will look like this:

tradingEngine.current.episode.episodeBaseAsset.balance.value

… or…

tradingEngine.current.episode.episodeQuotedAsset.balance.value

If you are not trading the entire balance on each position, then you may define the target size as a percentage of the balances, or in any other way you may see fit. For such cases, the following formula may be of use for the close stage target size:

tradingEngine.current.strategyOpenStage.stageBaseAsset.sizeFilled.value - tradingEngine.current.strategyOpenStage.stageBaseAsset.feesPaid.value

Of course, you may need to adjust the above to use stageBaseAsset or stageQuotedAsset, as required. In short, the formula returns the amount of the asset obtained by the transactions triggered during the open stage, minus the fees (and slippage, which is already subtracted from the size filled).

Adding a Target Size In Base Asset Node

To add the target size in base asset node, select Add Missing Items on the parent node menu.

Target Size In Quoted Asset

Target size in quoted asset is used to define the size of the position, denominating it in the quoted asset.

If you prefer to define the size of the position denominated in the quoted asset, then use this node and delete the target size in base asset node.

Adding a Target Size In Quoted Asset Node

To add the target size in quoted asset node, select Add Missing Items on the parent node menu.

Open Execution

The open execution node groups all execution algorithms involved in the process of opening a position.

One of the crucial elements that make up trading intelligence is the capacity to control every aspect of order execution, as the execution itself entails strategic elements that directly affect performance.

Superalgos’ trading engine is designed as a generic infrastructure that allows building execution logic from the ground up, with as much simplicity or complexity as may be required.

The trading system splits the definitions of the execution logic by trading strategy. That is, each strategy in a trading system may have its execution logic.

The next layer of control comes in the form of execution algorithms. Each strategy may have as many algorithms as required, and each algorithm may have as many instructions as required.

This model allows the granular control of orders with which you may build algorithms that may interact with other algorithms, and so on.

Adding an Open Execution Node

To add the open execution node, select Add Missing Items on the parent node menu.

Execution Algorithm

An execution algorithm is a set of instructions used to place and manage orders at the exchange.

Any given strategy may have simple or very complex execution requirements. To deal with complexity, Superalgos allows users to set up as many execution algorithms as required.

Then, the logic in each algorithm may remain simple, while the combined work of multiple algorithms may deal with the required complexity.

Each algorithm may be assigned a fraction of the target size (see the configuration section), thus, the extent of each algorithm’s involvement in the execution is defined by this parameter.

An execution algorithm is a set of instructions in the sense that the orders defined in each algorithm are themselves the instructions. That is, an execution algorithm is a set of predefined orders which may be created or canceled given specific market situations.

Adding an Execution Algorithm Node

To add the execution algorithm node, select Add Missing Items on the parent node menu.

Market Buy Order

A market buy order is an instruction sent to the exchange to buy the base asset, for immediate execution at current market prices.

Traders usually use market orders when the priority is the certainty of execution over the rate of execution. Depending on the size of the order and the liquidity of the particular market/exchange, market orders may experience more or less slippage.

Market Orders’ Rate

Users have no control over the rate at which a market order is filled. The exchange fills the order with available bids/asks at the time of execution.

Order Size

As explained in the definition of the execution algorithm, each algorithm is allocated a percentage of the target size defined under the initial targets node.

The simplified logic for non-coders:

algorithmSize = targetSize * percentageOfStageTargetSize / 100

The actual code:

let algorithmSizeInBaseAsset = tradingEngineStage.stageBaseAsset.targetSize.value * executionAlgorithm.config.percentageOfStageTargetSize / 100

let algorithmSizeInQuotedAsset = tradingEngineStage.stageQuotedAsset.targetSize.value * executionAlgorithm.config.percentageOfStageTargetSize / 100

Similarly, the size of an order is defined as a percentage of the size that the particular algorithm is allowed to execute (see the configuration).

The simplified logic for non-coders:

orderSize = algorithmSize * percentageOfAlgorithmSize / 100

The actual code:

tradingEngineOrder.orderBaseAsset.size.value = algorithmSizeInBaseAsset * tradingSystemOrder.config.percentageOfAlgorithmSize / 100

Because each execution algorithm may define multiple orders, the typical scenario is that all orders defined within an algorithm add up to 100% of the size allocated to the algorithm.

However, it is up to the user how to manage this setting, as different hacks may be found to achieve different behaviors.

If orders defined add up to more than 100% of the size allocated to the algorithm, the trading engine does not enforce a cap.

Pretty much like the user may decide to define the size of orders within an algorithm above or below the 100% mark, the same is true when defining multiple algorithms. In other words, the user may choose to set up algorithms whose combined sizes amount to more or less than 100%.

In cases in which the combined sizes amount to less than 100%, the target size would be partially filled at best. On the other hand, in cases in which the combined sizes amount to more than 100%, then the orders and/or algorithms would compete with each other.

The one validation the trading engine does is to enforce the target size defined under the initial targets node. The target size is treated as a hard cap, so that no position may ever be sized larger than the target.

If the order size as defined would cause the target size to be breached, then the order size is lowered to match the hard cap.

The simplified logic for non-coders:

if   ( targetSize + sizePlaced > targetSize )
     { orderSize = targetSize - sizePlaced }

The actual code:

if (
     tradingEngineOrder.orderBaseAsset.size.value + tradingEngineStage.stageBaseAsset.sizePlaced.value >
     tradingEngineStage.stageBaseAsset.targetSize.value
   ) {
     tradingEngineOrder.orderBaseAsset.size.value = tradingEngineStage.stageBaseAsset.targetSize.value - tradingEngineStage.stageBaseAsset.sizePlaced.value
   }
Placing and Filling of Orders

The trading engine keeps track of the amounts placed and the amounts filled based on the feedback obtained from the exchange, and makes the information available in the size placed and size filled nodes. The nodes are present in multiple contexts, such as the particular stage (open and close) or the particular order type, and are denominated both in the base asset and quoted asset. You may learn more about how to track the size placed and size filled on the trading engine pages.

Closing of Orders

Orders may be closed upon the occurrence of the following two events:

  • The exchange reports the order was filled. In such a case, the trading engine closes the order.

  • The cancel order event is triggered. This is an event the user may configure with the typical set up of situations and conditions.

Spawning Multiple Orders

All of the available types of orders may be configured so that multiple orders may be spawned, one after the other, through the same order definition.

This allows, for example, setting an order for 1% of the size allocated to the algorithm, and have the trading engine spawn one order per execution cycle until the 100% mark is reached. Such a feature may allow many more hacks and is yet another tool that—combined with the rest—enables a great deal of control over orders execution.

A new instance of an order may be spawned only under the following context:

  • The previous instance of the order is closed. That is, two instances of the same order may not exist at the same time.

  • The size filled at the level of the execution algorithm is within the limit established in the algorithm’s configuration.

  • The size filled at the level of the stage must be within the target size defined under the initial targets node.

Adding a Market Buy Order Node

To add the market buy order node, select Add Missing Items on the parent node menu.

Create Order Event

The create order event controls the placement of orders.

Even though the decision to take a position may have been made, the user may still decide to exert additional control over the placement of orders. Such is the intent of the create order event.

An order defined in an execution algorithm will be executed only if the event evaluates true.

If you wish orders to be placed as defined immediately after the take position event has been triggered, the use the statement true your only create order event condition.

Adding a Create Order Event Node

To add the create order event node, select Add Missing Items on the parent node menu.

Cancel Order Event

The cancel order event makes cancelling limit orders possible.

The cancel order event defines the market situations in which a limit order shall be canceled. When the event is triggered, the order is closed, even when the order may have been partially filled. In such a case, the size filled remains as is, and all accounts are computed accordingly, with the partial fill.

Adding a Cancel Order Event Node

To add the cancel order event node, select Add Missing Items on the parent node menu.

Simulated Exchange Events

The simulated exchange event node allows to override the parameters set at the level of the trading session on a per order basis to determine how each order shall be simulated.

The offspring nodes under simulated exchange events allow setting order-specific parameters for the size filled, actual rate, and fees paid, so that each order may be simulated in a specific manner.

If either of the offspring nodes is not present or is undefined, then the parameters configured at the level of the trading session are factored in by default.

Adding a Simulated Exchange Events Node

To add the simulated exchange events node, select Add Missing Items on the parent node menu.

Simulated Partial Fill

The simulated partial fill parameter allows simulating the partial fill of orders.

Upon each execution, the simulation verifies if the current candle intersects the rate set for the order. If it does, it uses the value in this parameter as a factor to determine and keep track of what percentage of the order is filled.

The same process repeats for each subsequent candle, until the order is filled.

When the parameter is not present or undefined, the simulation assumes the order is filled as soon as the rate is hit.

Adding a Simulated Partial Fill Node

To add the simulated partial fill node, select Add Missing Items on the parent node menu.

Simulated Actual Rate

The simulated actual rate node allows setting a specific rate value for the simulation of each order, overriding the slippage parameter of the trading session.

The slippage parameter of the trading session allows setting a blanket slippage for all orders in the trading system. The simulated actual rate node allows control on a per-order basis, so each order may be simulated with a specific rate.

Adding a Simulated Actual Rate Node

To add the simulated actual rate node, select Add Missing Items on the parent node menu.

Simulated Fees Paid

The simulated fees paid node allows setting a specific fee for the simulation of each order, overriding the fee structure parameter of the trading session.

The fee structure parameter of the trading session allows setting a blanket fee structure (maker and taker) for all orders in the trading system. The simulated fees paid node allows control on a per-order basis, so each order may be simulated with a specific fee.

Adding a Simulated Fees Paid Node

To add the simulated fees paid node, select Add Missing Items on the parent node menu.

Market Sell Order

A market sell order is an instruction sent to the exchange to sell the base asset, for immediate execution at current market prices.

Adding a Market Sell Order Node

To add the market sell order node, select Add Missing Items on the parent node menu.

Limit Buy Order

A limit buy order is an instruction sent to the exchange to buy the base asset, for execution at a specific rate or better.

Traders usually use limit orders when the priority is the rate of execution over the certainty of execution. Limit orders are much more efficient than market orders in terms of rate, particularly for larger sizes which—when executed as market orders—may suffer considerable slippage filled as fast as possible with the order book of the particular instant.

Also, many exchanges regard limit orders as market makers, that is, orders that bring liquidity to the market, and, therefore, may charge relatively better fees.

Limit Orders’ Rate

Superalgos users must define the rate at wish they wish the order to be filled. The exchange is responsible for not filling the order unless it can match it with bids/asks at the rate set by the user, or at a better rate.

Small discrepancies between the actual rate and the order rate are to be expected, as not all exchanges handle decimals and other conversions involving, for example, fees, in the same manner.

Adding a Limit Buy Order Node

To add the limit buy order node, select Add Missing Items on the parent node menu.

Order Rate

The order rate node defines the rate of limit orders.

Because the purpose of limit orders is to have control over the rate at which the order is executed, the definition of the order rate is required for all limit orders.

Adding an Order Rate Node

To add the order rate node, select Add Missing Items on the parent node menu.

Limit Sell Order

A limit sell order is an instruction sent to the exchange to sell the base asset, for execution at a specific rate or better.

Adding a Limit Sell Order Node

To add the limit sell order node, select Add Missing Items on the parent node menu.

Close Stage Event

The close stage event defines the set of rules that need to be met for the corresponding stage to be closed.

Both the open and close stages are closed once the target size is filled.

However, Superalgos allows an extra level of control so that the user may choose to close either stage given specific market situations. Such is the intent of the close stage event.

Adding a Close Stage Event Node

To add the close stage event node, select Add Missing Items on the parent node menu.

Manage Stage

The manage stage deals with the setting and management of stop loss and take profit targets, both to protect your capital and to increase the efficiency of your trading system.

The first and foremost rule of trading is to preserve capital and its main goal is to increase it.

Conceptually, a position is not an instantaneous event, but an event which has an opening, a period of maturation, and a closing. The management of the position happens throughout the process.

The concept of managing the position refers to the fact that the formulas that determine the take profit and stop loss targets may change as the position develops. A typical situation in which you may want to change your original take profit and stop loss formulas is when the position seems to be developing well in your favor.

It may be in your best interest to manage the stop loss, moving the target in the direction that would help protect unrealized profits. It may also be in your interest to move the take profit target to extract a larger profit than originally expected. Or you may wish to set up a mechanism that closes the trade as soon as a certain market situation materializes.

The management of take profit and stop loss is done independently of each other, in phases. Therefore, each concept has its own set of management phases.

Each phase has its formula to describe the corresponding target. Users may define situations in which the current phase shall be abandoned and a different phase—with its formula—shall be implemented.

Keep in mind that the position is in constant development, so there may be as many phases as you deem appropriate for your particular strategy.

The idea of managing targets in phases derives from the notion that big market moves tend to provide clues as to what may come up next. For instance, rallies may accelerate as more traders join the move. Recognizable patterns may emerge. Signs of exhaustion may be identified.

All of these considerations may feed the dynamic analysis performed in each phase as the position develops.

Upon execution, the system verifies if the current candle has tagged either of the targets. If—or when—it does, the close stage kicks in and closing execution begins.

It is crucial to understand that Superalgos does not place orders to close a position until the stop loss or take profit targets are hit. That is, stop loss and take profit are not orders sitting at the exchange waiting to be filled at a certain rate. Instead, Superalgos keeps track of targets internally, and places the orders at the exchange during the execution cycle in which it detects either of the targets has been hit.

This behavior has advantages and disadvantages, but it was designed as is because the former outweigh the latter.

By not placing stop or take profit orders at the exchange, Superalgos keeps your targets—and the underlying strategy—secret. This guarantees that such a crucial piece of information may not be used against you by the exchange itself or any third party that may have access to privileged information.

On the other hand, not placing a stop order in advance may occasionally cause relatively more slippage, for instance, in cases of massive flash market moves.

That said, the default behavior of the system may be hacked to avoid the eventual risk of excessive slippage: set your stop loss and take profit targets tighter than intended.

Adding the Manage Stage Node

To add a manage stage node, select Add Missing Stages on the strategy node menu. All stages that may be missing are created along with the rest of the basic structure of nodes required to define each of them and their events.

Managed Stop Loss

The managed stop loss node features the definition of the phases that make up the management of the stop loss target as the position develops.

Adding a Managed Stop Loss Node

To add a stop node, select Add Missing Items on the manage stage node menu. All items that may be missing are created along with the rest of the basic structure of nodes required to define each of them.

Phase

The management of take profit and stop loss targets is done in phases. Phase 1 sets the initial targets, either for the managed stop loss or the managed take profit, and becomes active as soon as the first order is placed. Subsequent phases allows switching to different formulas given certain market situations.

The default management of phases is sequential, meaning that phase 2 comes after phase 1, phase 3 comes after phase 2, and so on.

To switch from one phase to the next phase in the sequence, the next phase event is used. When the situation described in the next phase event validates true, the switch occurs and the next phase becomes the active phase.

However, management does not need to happen sequentially. By using the move to phase event instead of the next phase event, the system may activate any other phase and not just the one next in the sequence.

Both events may be used at the same time, and whichever event is triggered first takes precedence.

Adding a Phase Node

To add a new phase, select Add Phase on the stop or take-profit node menu. A new phase is added along with the basic structure of nodes required to define each of them and their events.

Next Phase Event

The next phase event determines when there should be a switch of phases to the next phase in a predefined sequence.

The management of a position is —by default—done in sequential phases, each phase with its formula. To move from one phase to the next, a situation you define must be validated.

When that happens, the next phase event is triggered, the current phase is abandoned, and the next phase is activated. From that instant on, the system evaluates the formula corresponding to the next phase.

The sequence of phases may be as long as the number of phases you choose to add and define. There may be unlimited numbers of phases.

Adding a Next Phase Event Node

To add a next phase event, select Add Next Phase Event on the corresponding phase node menu. The event is added along with the basic structure of nodes to define it.

Move to Phase Event

The move to phase event determines when there should be a switch of phases from the current phase to an arbitrary phase determined by a reference.

While phases are defined in a sequence and you may choose to manage the position by shifting from one phase to the next in the sequence, the move to phase event offers an alternative.

With the move to phase event, you may arbitrarily decide which will be the next phase. To do that, you must establish a reference from the move to phase event, to the phase that should be activated once the event is triggered.

Any number of move-to-phase events may be set up for each and every phase, allowing complete flexibility on how the position is managed. This feature allows setting up versatile position-management algorithms that may switch to different formulas back and forth, or in any configuration imaginable.

Adding a Move to Phase Event Node

To add a move-to-phase event, select Add Move to Phase Event on the corresponding phase node menu. The event is added along with the basic structure of nodes to define it.

Managed Take Profit

The managed take profit node features the definition of the phases that make up the management of the take profit target as the position develops.

Adding a Managed Take Profit Node

To add a take profit node, select Add Missing Items on the manage stage node menu. All items that may be missing are created along with the rest of the basic structure of nodes required to define each of them.

Close Stage

The close stage deals with the definitions that make up the logic to close a position, including the target rate and size, and order execution.

The close stage is opened when either the stop loss or take profit targets are hit.

In a way, the close stage is virtually a mirror of the open stage, as the same definitions are required to close a position. There are a few logical differences, though.

For example, in the open stage, you probably defined the target size as a function of the capital allocated to the trading system. In the close stage, you will likely want to define the target size as a function of the size filled, that is, the amount of the orders placed that was filled during the open stage.

Adding the Close Stage Node

To add a close stage node, select Add Missing Stages on the strategy node menu. All stages that may be missing are created along with the rest of the basic structure of nodes required to define each of them and their events.

Close Execution

The close execution node groups all execution algorithms involved in the process of closing a position.

The close execution section of the close stage works similarly to the open execution in the open stage. Please refer to the explanations of the open stage for the details.

Adding the Close Execution Node

To add a close execution node, select Add Close Execution on the open stage node menu.