Available translations

Open Stage Execution

Summary: This section of the Open Stage handles the logic and orders used to enter a Position.
Open Execution
Foundations->Node->Open Execution->Definition
The open execution node groups all execution algorithms involved in the process of opening a position.
Foundations->Node->Open Execution->Content
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.
Foundations->Concept->Reusable Snippets->Note for Hierarchy Tables
Execution Algorithm
Execution Algorithm
Foundations->Node->Execution Algorithm->Definition
An execution algorithm is a set of instructions used to place and manage orders at the exchange.
Foundations->Node->Execution Algorithm->Content
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.
Market Buy Order
Foundations->Node->Market Buy Order->Definition
A market buy order is an instruction sent to the exchange to buy the base asset, for immediate execution at current market prices.
Foundations->Node->Market Buy Order->Content
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 >
) {
     tradingEngineOrder.orderBaseAsset.size.value = 
     tradingEngineStage.stageBaseAsset.targetSize.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.
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.
Market Sell Order
Foundations->Node->Market Sell Order->Definition
A market sell order is an instruction sent to the exchange to sell the base asset, for immediate execution at current market prices.
Foundations->Node->Market Sell Order->Content
Limit Buy Order
Foundations->Node->Limit Buy Order->Definition
A limit order is an order to buy or sell a security at a specific price or better. A buy limit order can only be executed at the limit price or lower, and a sell limit order can only be executed at the limit price or higher.
Foundations->Node->Limit Buy Order->Content
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 Order 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.
Limit Sell Order
Foundations->Node->Limit Sell Order->Definition
A limit sell order is an instruction sent to the exchange to sell the base asset, for execution at a specific rate or better.
Foundations->Node->Limit Sell Order->Content
Open Stage Initial Targets
Order Definitions