Learn about the Open Execution, Execution Algorithm, Market Buy Order, Market Sell Order, Limit Buy Order, Limit Sell Order, Create Order Event, Simulated Exchange Events, Simulated Partial Fill, Simulated Actual Rate, Simulated Fees Paid, and Order Rate

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.


Open Stage

Initial Targets

Open Execution

Execution Algorithm

Market Buy Order

Market Sell Order

Limit Buy Order

Limit Sell Order

Order Rate

Formula

Create Order Event

Cancel Order Event

Simulated Exchange Events

Simulated Partial Fill

Simulated Actual Rate

Formula

Simulated Fees Paid

Close Stage Event

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.

Click to learn more about execution algorithms

Configuring the Execution Algorithm

To configure the execution algorithm node, select Configure on the menu.

{
     "percentageOfStageTargetSize": 100 
}
  • percentageOfStageTargetSize is the definition of how much of the target size of the whole stage will be handled by the one specific execution algorithm, expressed as a percentage of the total target size. Posible values are real numbers between 0 and 100, including the extremes. If you set the value to 0, the algorithm will not be executed.

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.

Click to learn more about market buy orders

Configuring the Market Buy Order

To configure the market buy order node, select Configure on the menu.

{
     "percentageOfAlgorithmSize": 100, 
     "spawnMultipleOrders": false 
}
  • percentageOfAlgorithmSize is the definition of how much of the size handled by the algorithm shall be allocated to this particular order. Posible values are real numbers between 0 and 100, including the extremes. If you set the value to 0, the order will not be executed.

  • spawnMultipleOrders is the parameter that indicates whether additional spawned orders are allowed (true) or not (false).

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.

Click to learn more about market sell orders

Configuring the Market Sell Order

To configure the market sell order node, select Configure on the menu.

{
     "percentageOfAlgorithmSize": 100, 
     "spawnMultipleOrders": false 
}
  • percentageOfAlgorithmSize is the definition of how much of the size handled by the algorithm shall be allocated to this particular order. Posible values are real numbers between 0 and 100, including the extremes. If you set the value to 0, the order will not be executed.

  • spawnMultipleOrders is the parameter that indicates whether additional spawned orders are allowed (true) or not (false).

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.

Click to learn more about limit buy orders

Configuring the Limit Buy Order

To configure the limit buy order node, select Configure on the menu.

{
     "percentageOfAlgorithmSize": 100, 
     "spawnMultipleOrders": false 
}
  • percentageOfAlgorithmSize is the definition of how much of the size handled by the algorithm shall be allocated to this particular order. Posible values are real numbers between 0 and 100, including the extremes. If you set the value to 0, the order will not be executed.

  • spawnMultipleOrders is the parameter that indicates whether additional spawned orders are allowed (true) or not (false).

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.

Click to learn more about limit sell orders

Configuring the Limit Sell Order

To configure the limit sell order node, select Configure on the menu.

{
     "percentageOfAlgorithmSize": 100, 
     "spawnMultipleOrders": false 
}
  • percentageOfAlgorithmSize is the definition of how much of the size handled by the algorithm shall be allocated to this particular order. Posible values are real numbers between 0 and 100, including the extremes. If you set the value to 0, the order will not be executed.

  • spawnMultipleOrders is the parameter that indicates whether additional spawned orders are allowed (true) or not (false).

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.

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.

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.

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.

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.

Click to learn more about simulated partial fills

Configuring the Simulated Partial Fill

To configure the simulated partial fill node, select Configure on the menu.

{ 
     "fillProbability": 1
}
  • fillProbability indicates the probability of an order getting filled upon each tag of the price. Values may range from 0 to 1. The value 0 indicates that there are 0% chances of the order getting filled. With such a setting, the order will never get filled in the simulation. The value 1 indicates that there is a 100% probability of the order getting filled. With such a setting, the order is filled upon the first tag of the price. A value of 0.5 indicates a 50% probability, thus, it takes two tags of the price for the order to fill completely with such a setting.
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.

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.

Click to learn more about simulated fees paids

Configuring the Simulated Fees Paid

To configure the simulated fees paid node, select Configure on the menu.

{ 
"percentage": 0.1
}
  • percentage is the percentage to be applied to calculate the fees for the specific order.