Strategy mechanics - TakeProfit

This article describes how strategies execute — in both backtesting and live trading — and will help you write more accurate and reliable strategies.

Backtesting vs live trading

Strategies run in two modes from the same code:

Backtesting (including forward-testing on real-time bars) runs against a built-in exchange emulator that simulates order fills, fees, and margin on historical and live bars.
Live trading sends real orders to a real exchange and reacts to real fills.

Most behavior is identical by design. But because one side is simulated and the other is a real venue, a few things necessarily differ. Use this section as the reference for what is the same, what is simulated only, and what is live only.

Identical in both modes (strategy behavior)

These belong to the strategy itself, so they behave the same whether you backtest or trade live:

Order lifecycle and statuses — the states an order goes through (see Statuses and lifecycle).
Execution delays — placing, updating, or canceling an order takes effect on the next tick, never instantly (see Order execution below).
intrabar_order_filter — NO_FILTER / ON_BAR_CLOSE / FIRST_IN_BAR / LAST_IN_BAR gate order placements and cancels/amends identically (see Order filtering).
Capital, leverage, and margin — the strategy keeps its own books on initial_capital and leverage. A margin call (cannot open or increase the position) and a stop-out (all orders canceled, position force-closed, strategy halted) can happen to the strategy based on its own equity, independently of the state of your overall exchange account (see Margin trading).

Simulated only (backtesting)

The emulator has to invent things that a real exchange decides for you:

Fill prices and timing are simulated against each bar’s OHLC (limit/stop trigger logic, intrabar replay). In live trading, fills are real, asynchronous events from the exchange, so the exact fill price and the tick on which a fill arrives will differ from the simulation.
market_order_price (MARKET_PRICE / ORDER_CREATION_PRICE / BAR_OPEN_PRICE) affects backtesting only — it forces the simulated fill price. In live trading the fill price is whatever the exchange gives you and cannot be forced.
Commissions use the commission model you configure. In live trading the real exchange fees from each execution apply instead, so cash and equity evolve slightly differently even for identical fills.

Live only (real exchange)

Order execution is the exchange’s job. Fills, partial fills, and the triggering of stop/limit and take-profit/stop-loss orders follow the real exchange’s rules and latency, not the emulator’s.
Take-profit / stop-loss are attached to the order and sent to the exchange. The position-level TP/SL behavior described in Take-profit and stop-loss orders is how the emulator models it (matching Bybit); other exchanges may handle brackets differently.

Live trading runs the same strategy code as backtesting, but a backtest is an approximation of live performance, not a guarantee. The differences above — simulated vs real fill prices, the configured commission vs real exchange fees, and exchange-side execution and latency — mean a live run can diverge from its backtest.

Order execution

When trading on a real exchange, your actions cannot be executed instantly. It takes time for a request to reach the exchange, for the order to be added to the order book, for it to be executed, and for the execution notification to return to you. When writing and backtesting strategies, traders often overlook these delays and fail to account for them. As a result, a strategy may behave very differently in live trading compared to backtesting. To address this, our backtesting engine simulates these real-world delays. This means that actions in your code do not take effect immediately. Instead, they are applied with a delay, and the results of those actions become visible only on the next price tick, when the strategy is recalculated. The following examples illustrate how these delays affect strategy behavior in different scenarios:

Example 1: Order submission delay

When you create an order, it is not filled immediately. The order must first be sent to the exchange, accepted, and then executed. This example demonstrates that you cannot see the filled status immediately after calling submit():

# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional, IndieError
from indie.strategies import order_side, Order, order_status

@strategy('Order Submission Delay')
class Main(MainStrategyContext):
    def __init__(self):
        self._order: Optional[Order] = None
        self._step = 0

    def calc(self):
        if self._step == 0:
            # Create an order
            self._order = self.trading.place_order(order_side.BUY, size=1).submit()
            # Check: order should NOT be filled immediately
            if self._order.value().status == order_status.FILLED:
                raise IndieError('Order should not be filled immediately after creation')
            self._step = 1
        elif self._step == 1:
            # On the next calc call, the order should be filled
            if self._order.value().status != order_status.FILLED:
                raise IndieError('Order should be filled by now')
            self._step = 0

Example 2: Order update delay

When you update an order’s parameters (e.g., limit price), the changes are not applied immediately. This example shows that the order properties reflect the update only on the next calc() call:

# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional, IndieError
from indie.strategies import order_side, Order, order_status

@strategy('Order Update Delay')
class Main(MainStrategyContext):
    def __init__(self):
        self._order: Optional[Order] = None
        self._step = 0

    def calc(self):
        if self._step == 0:
            # Create an order with a limit price that won't execute
            self._order = (
                self.trading.place_order(order_side.SELL, size=1).
                limit(self.high[0] * 10).
                submit()
            )
            self._step = 1
        elif self._step == 1:
            # Update the limit price to a value that will execute
            new_limit = self.low[0] / 10
            (
                self.trading.amend_order(self._order.value().id).
                limit(new_limit).
                submit()
            )
            # Check: the limit should NOT be updated immediately
            if self._order.value().limit.value() == new_limit:
                raise IndieError('Order cannot be updated immediately')
            self._step = 2
        elif self._step == 2:
            # On the next calc call, the new limit should be applied and order filled
            if self._order.value().limit.value() >= self.high[0]:
                raise IndieError('Order limit was not updated correctly')
            if self._order.value().status != order_status.FILLED:
                raise IndieError('Order should be filled by now')
            self._step = 0

Example 3: Order cancellation delay

When you cancel an order, it is not canceled immediately. The cancellation request must be sent to the exchange and processed. This example demonstrates the delay:

# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional, IndieError
from indie.strategies import order_side, Order, order_status

@strategy('Order Cancellation Delay')
class Main(MainStrategyContext):
    def __init__(self):
        self._order: Optional[Order] = None
        self._step = 0

    def calc(self):
        if self._step == 0:
            # Create an order with a limit price that won't execute
            self._order = (
                self.trading.place_order(order_side.SELL, size=1).
                limit(self.high[0] * 10).
                submit()
            )
            self._step = 1
        elif self._step == 1:
            # Cancel the order
            self.trading.cancel_order(self._order.value().id)
            # Check: order should NOT be canceled immediately
            if self._order.value().status == order_status.CANCELED:
                raise IndieError('Order should not be cancelled immediately')
            self._step = 2
        elif self._step == 2:
            # On the next calc call, the order should be canceled
            if self._order.value().status != order_status.CANCELED:
                raise IndieError('Order should be cancelled by now')
            self._step = 0

Example 4: Immediate update after creation

When you create and immediately update an order in the same calc() call, the system applies the update locally before sending the order to the exchange. This means the order is sent with the updated parameters:

# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional, IndieError
from indie.strategies import order_side, Order, order_status

@strategy('Immediate Update After Creation')
class Main(MainStrategyContext):
    def __init__(self):
        self._order: Optional[Order] = None
        self._step = 0

    def calc(self):
        if self._step == 0:
            # Create an order with a high limit price
            self._order = (
                self.trading.place_order(order_side.SELL, size=1).
                limit(self.high[0] * 10).
                submit()
            )
            # Immediately update it to a price that will execute
            new_limit = self.low[0] / 10
            (
                self.trading.amend_order(self._order.value().id).
                limit(new_limit).
                submit()
            )
            self._step = 1
        elif self._step == 1:
            # On the next calc call, the order should have the updated limit and be filled
            # NOTE: When you create and modify an order in the same calc call,
            # the update is applied locally before the order is sent to the exchange.
            # The exchange receives the order with the already updated parameters.
            if self._order.value().limit.value() >= self.high[0]:
                raise IndieError('Order limit was not updated correctly')
            if self._order.value().status != order_status.FILLED:
                raise IndieError('Order should be filled by now')
            self._step = 0

Key takeaway: Always account for execution delays when writing strategies. Order operations (creation, updates, cancellations) take effect on the next calc() call, not immediately. This behavior ensures your strategy works more consistently in both backtesting and live trading environments.

Fail-safe order operations

Some operations performed by a strategy — such as canceling or updating an order — are handled safely. This means the strategy will not fail if you call cancel or amend on an order that has already been canceled or executed. In such cases, the invalid operation is simply ignored. This simplifies your code and removes the need for additional if statements in situations where you want to “cancel an order if it hasn’t been executed or canceled yet” or “update an order if it’s still active”. The example below demonstrates a strategy that places sell limit orders and then cancels or updates them based on price movement — without checking the order status before each operation:

# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional
from indie.strategies import order_side, Order, order_status


@strategy('Fail-Safe Order Operations', overlay_main_pane=True)
class Main(MainStrategyContext):
    def __init__(self):
        self._sell_order: Optional[Order] = None

    def calc(self):
        if self.close[0] < self.close[1]:  # price starts falling -> place sell order
            if self._sell_order is None or self._sell_order.value().status == order_status.FILLED:
                limit_price = self.close[0] * 0.99
                self._sell_order = (
                    self.trading.place_order(order_side.SELL, size=1).
                    limit(limit_price).
                    submit()
                )
        elif self.close[0] > self.close[3]:  # price rising during three bars -> cancel sell order
            if self._sell_order is not None:
                # Note: we don't check if the order was already filled or canceled
                # The system will safely ignore the cancellation if the order is no longer active
                self.trading.cancel_order(self._sell_order.value().id)
                self._sell_order = None
        elif self.close[0] > self.close[1]:  # short price correction -> we can sell at a better price -> update order
            if self._sell_order is not None:
                # Note: we don't check if the order was already filled
                # The system will safely ignore the amend operation if the order is no longer active
                new_limit_price = self.close[0] * 0.99
                (
                    self.trading.amend_order(self._sell_order.value().id).
                    limit(new_limit_price).
                    submit()
                )

Key takeaway: In this example, we call both cancel_order() and amend_order() without explicitly checking the order status beforehand. If the order has already been filled, canceled, or rejected, these operations will be safely ignored without throwing an exception. This simplifies your code by removing the need for defensive status checks.

Order filtering (`intrabar_order_filter` parameter)

Inside a bar, the price moves. While the current candle is not finished, the strategy receives updates for the current candle. The strategy does not remember all intermediate values; only the latest, most actual value of the current candle is available in the strategy. If the logic of the strategy is based on comparing the current candle with the previous closed candle, then you may get false positive triggers. They can be avoided by additional checks in the code or by using our pre-configured filter intrabar_order_filter. Possible values for intrabar_order_filter:

intrabar_order_filter.NO_FILTER: No intrabar filtering is applied. Orders can be placed or modified at any price update within a candle.
intrabar_order_filter.ON_BAR_CLOSE: Orders can be placed or modified only at the close of the candle. Other submits of place_order will be rejected with the REJECTED status.
intrabar_order_filter.FIRST_IN_BAR: Only the first batch of orders within a bar is accepted. Orders can be placed on any price update, but once a calc() call places orders, all orders from subsequent calc() calls within the same bar are ignored (rejected with the REJECTED status).
intrabar_order_filter.LAST_IN_BAR: Only the last batch of orders within a bar is applied. All orders placed during a calc() call are accepted, but if a new calc() call places orders, the previous batch is replaced by the new one. The final batch is applied when the next bar starts.

Let’s look in more detail with an example. Suppose the price changes like this:

    candle1    |    candle2     |    candle3     |
41.0 41.4 41.8 | 42.2 42.6 43.0 | 43.4 43.8 44.2 |

# 3 price updates during each candle

We want to place an order when the price crosses the 42.0 level:

    candle1    |    candle2     |    candle3     |
41.0 41.4 41.8 | 42.2 42.6 43.0 | 43.4 43.8 44.2 |
                  ^
      42.2 > 42.0 and 41.8 < 42.0
          crossing detected,
            order placing

We want to write code like this:

# current price is above the level and previous candle closed below it
if self.close[0] > 42.0 and self.close[1] < 42.0:
    self.trading.place_order(...).submit()

But the strategy’s Main function is called on each price update, not only on bar close. Since we compare the current price to the previous bar’s close, this will result in extra triggers:

    candle1    |                 candle2                  |    candle3     |
41.0 41.4 41.8 | 42.2              42.6              43.0 | 43.4 43.8 44.2 |
                  ^                 ^                 ^
             42.2 > 42.0       42.6 > 42.0       43.0 > 42.0
             41.8 < 42.0       41.8 < 42.0       41.8 < 42.0
           cross detected    cross detected    cross detected

Therefore, we need to add extra logic to prevent duplicate orders. Depending on the specific situation, different approaches may be appropriate.

Manual trigger filtering: previous price comparison

We can compare it not with the previous bar’s price but with the last received tick price, if you store it in a variable:

# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Manual Filter - Previous Price Comparison', intrabar_order_filter=intrabar_order_filter.NO_FILTER)
class Main(MainStrategyContext):
    def __init__(self):
        self._prev_price = 0.0

    def calc(self):
        if self.bar_index > 0:
            if self._prev_price < 42.0 and self.close[0] > 42.0:
                self.trading.place_order(...).submit()
        self._prev_price = self.close[0]

Manual trigger filtering: trigger at bar close

We can detect the crossing and place an order only at bar close:

# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Manual Filter - Bar Close Trigger', intrabar_order_filter=intrabar_order_filter.NO_FILTER)
def Main(self):
    if self.is_closed_bar:
        if self.close[1] < 42.0 and self.close[0] > 42.0:
            self.trading.place_order(...).submit()

Manual trigger filtering: only first trigger during bar

We can ensure that only one order is placed per bar (not necessarily at bar close):

# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Manual Filter - First Trigger Only', intrabar_order_filter=intrabar_order_filter.NO_FILTER)
class Main(MainStrategyContext):
    def __init__(self):
        self._last_order_time = 0.0

    def calc(self):
        if self._last_order_time < self.time[0] and self.close[1] < 42.0 and self.close[0] > 42.0:
            self.trading.place_order(...).submit()
            self._last_order_time = self.time[0]

But all of these approaches require additional logic in the code. To avoid writing extra checks, we introduced several pre-configured filters for controlling when orders are placed.

`intrabar_order_filter.ON_BAR_CLOSE`

To place orders only at bar close:

# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Auto Filter - On Bar Close', intrabar_order_filter=intrabar_order_filter.ON_BAR_CLOSE)
def Main(self):
    # not necessary to manually check if it is a closed bar
    if self.close[1] < 42.0 and self.close[0] > 42.0:
        self.trading.place_order(...).submit()

`intrabar_order_filter.FIRST_IN_BAR`

Only the first batch of orders within a bar is accepted. Orders can be placed on any price update, but once a calc() call places orders, all orders from subsequent calc() calls within the same bar are ignored until the next bar. You can place multiple orders in the same calc() call and they will all go through. The same rules apply to cancel_order and amend_order — see below.

# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Auto Filter - First In Bar', intrabar_order_filter=intrabar_order_filter.FIRST_IN_BAR)
def Main(self):
    # not necessary to store the last order time
    if self.close[1] < 42.0 and self.close[0] > 42.0:
        self.trading.place_order(...).submit()

`intrabar_order_filter.LAST_IN_BAR`

Only the last batch of orders within a bar is applied. You can place multiple orders in the same calc() call and they will all be accepted, but if a new calc() call places orders, the entire previous batch is replaced by the new one. The final batch is applied when the next bar starts. The same rules apply to cancel_order and amend_order — see below.

# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import intrabar_order_filter

@strategy('Auto Filter - Last In Bar', intrabar_order_filter=intrabar_order_filter.LAST_IN_BAR)
def Main(self):
    # not necessary to store the last order time
    if self.close[1] < 42.0 and self.close[0] > 42.0:
        self.trading.place_order(...).submit()

Note that to determine the last batch of orders within the bar, the emulator waits for the bar to close and then applies the final batch before placing orders on the next bar.

`intrabar_order_filter.NO_FILTER`

Finally, if none of these filters fit your needs and you want full control over when orders are placed, you can use the NO_FILTER setting, as shown in the examples above.

How filtering applies to `cancel_order` and `amend_order`

The intrabar_order_filter parameter controls not only place_order, but also cancel_order and amend_order commands. The filtering rules are the same as for order placement:

NO_FILTER: cancel_order and amend_order are accepted on any price update and applied on the next tick.
ON_BAR_CLOSE: cancel_order and amend_order calls are only accepted at bar close. Calls during intrabar ticks are silently ignored.
FIRST_IN_BAR: The first batch of cancel_order/amend_order calls in a bar is accepted. You can issue multiple commands in the same calc() call and they will all go through. Commands from subsequent calc() calls within the same bar are ignored.
LAST_IN_BAR: All cancel_order/amend_order calls within a calc() call are accepted as a batch. If a new calc() call issues commands, the entire previous batch is replaced. The final batch is applied when the next bar starts.

For example, with FIRST_IN_BAR you can cancel two orders in a single calc() call and both will be canceled. But if you cancel one order on the first price update and try to cancel another on the next update, the second cancel will be ignored:

# indie:lang_version = 5
from indie import strategy, MainStrategyContext, Optional
from indie.strategies import order_side, Order, order_status, intrabar_order_filter


@strategy('Cancel/Amend with FIRST_IN_BAR', intrabar_order_filter=intrabar_order_filter.FIRST_IN_BAR)
class Main(MainStrategyContext):
    def __init__(self):
        self._order_a: Optional[Order] = None
        self._order_b: Optional[Order] = None

    def calc(self):
        if self._order_a is not None and self._order_b is not None:
            # Both cancels are in the same calc() call — both will be accepted
            self.trading.cancel_order(self._order_a.value().id)
            self.trading.cancel_order(self._order_b.value().id)

With LAST_IN_BAR, if you cancel an order on one price update and then cancel a different order on the next update, the first cancel is replaced by the second — only the second cancel will be applied when the next bar starts.

Price for market orders (`market_order_price` parameter)

This parameter affects backtesting only. It forces the simulated fill price of market orders. In live trading the fill price is set by the real exchange and cannot be forced.

By default, market orders are executed at the price the instrument has at the moment of execution. Note that the execution time of an order does not match the moment you place it or the moment you call place_order() (see the Order execution section above). This behavior reflects real-world execution, but during backtesting traders sometimes want to force a specific execution price for testing purposes. You can configure which value will be used as the execution price for market orders. There are three available options:

market_order_price.MARKET_PRICE: the actual market price at the time of execution (default)
market_order_price.ORDER_CREATION_PRICE: the price at which the order was created
market_order_price.BAR_OPEN_PRICE: the opening price of the bar in which the order was created

# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import market_order_price

@strategy('Market Order at Creation Price', market_order_price=market_order_price.ORDER_CREATION_PRICE)
def Main(self):
    pass

This setting applies to the entire strategy run. It cannot be changed at runtime, so all market orders within a single run use the same configuration.

Simulation of trading at market close

The configuration described above can be useful when you want to simulate trading at market close using a price close to the bar’s closing value. To achieve this, you should place an order right before the session ends, using the bar’s closing price. This can be done by combining the market_order_price and intrabar_order_filter parameters.

# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import order_side, market_order_price, intrabar_order_filter


@strategy('Trading at Market Close',
          intrabar_order_filter=intrabar_order_filter.ON_BAR_CLOSE,
          market_order_price=market_order_price.ORDER_CREATION_PRICE)
def Main(self):
    # just buying at the bar closing price
    self.trading.place_order(order_side.BUY, size=42.0).submit()

Simulation of trading at market open

Similarly, by combining the market_order_price and intrabar_order_filter parameters, you can execute an order at the current bar’s opening price to simulate trading at market open.

# indie:lang_version = 5
from indie import strategy, MainStrategyContext
from indie.strategies import order_side, market_order_price, intrabar_order_filter


@strategy('Trading at Market Open',
          intrabar_order_filter=intrabar_order_filter.FIRST_IN_BAR,
          market_order_price=market_order_price.BAR_OPEN_PRICE)
def Main(self):
    # just buying at the bar opening price
    self.trading.place_order(order_side.BUY, size=42.0).submit()

Margin trading (`leverage` parameter)

Margin is the strategy’s own accounting on initial_capital and leverage, so it works the same in backtesting and live trading. A margin call (the strategy can no longer open or increase a position) and a stop-out (all its orders are canceled, the position is force-closed, and the strategy stops trading) can happen to the strategy from its own equity — even if your overall exchange account is fine.

Margin trading allows traders to borrow funds to increase their buying power, enabling them to open positions larger than their available capital. This is achieved by leveraging the trader’s initial capital as collateral. If the leverage parameter is greater than 1.0, the strategy can open positions larger than the available capital.

Leverage: The ratio of the trader’s position size to their own capital. For example, a leverage of 2.0 means the trader can open positions twice the size of their capital.
Initial margin: The minimum amount of the trader’s own funds required to open leveraged positions. If the portfolio value falls below the initial margin, the trader must reduce exposure. The trader cannot open new or increase existing uncovered positions.
Maintenance Margin: The amount of collateral at which positions are forcibly closed. The maintenance margin is usually 1/2 of the initial margin.
Equity: The trader’s total capital, including unrealized profits and losses, minus any liabilities.
Margin Call: A warning issued when equity falls below the initial margin, requiring the trader to add funds or reduce exposure to avoid liquidation.
Stop Out: The forced closure of positions when equity falls below the maintenance margin level.

Example Scenario: imagine a trader with $10,000 in capital and a max allowed leverage of 3.0. The trader opens a position worth $20,000 ($10,000 of their own and $10,000 provided by the broker on loan, current leverage is 2x). If the market moves against the trader and their equity falls below the initial margin requirement (e.g., $5,000), they will receive a margin call. If their equity continues to decline and falls below the maintenance margin requirement (e.g., $2,500), the broker will close the trader’s position to limit losses (stop-out). Risks of Margin Trading:

Amplified Losses: While leverage can increase profits, it also magnifies losses.
Liquidation Risk: Failure to meet margin requirements can result in the forced closure of positions.
Interest Costs: Borrowed funds may accrue interest, adding to the cost of trading.

Using leverage works best when it’s part of a clear plan: knowing how much risk you’re willing to take, how much the position can move against you, and when you’re ready to exit. Example of a strategy using leverage:

# indie:lang_version = 5
from indie import strategy
from indie.strategies import order_side


@strategy(
    'Leverage Example', overlay_main_pane=True,
    initial_capital=100000.0, leverage=10.0)  # allow margin trading with 10x leverage
def Main(self):
    pos_size = self.trading.position.size
    if pos_size == 0:
        current_cash = self.trading.cash
        allowed_size_to_buy_with_own_money = current_cash / self.close[0]
        # we can buy more than our own money but not more than 10x
        order_size = allowed_size_to_buy_with_own_money * 2.0  # 2x leverage is OK, because 2 < 10

        # open the position with leverage
        self.trading.place_order(order_side.BUY, size=order_size).submit()
    else:
        # close the position
        self.trading.place_order(order_side.SELL, size=pos_size).submit()

​Backtesting vs live trading

​Identical in both modes (strategy behavior)

​Simulated only (backtesting)

​Live only (real exchange)

​Order execution

​Example 1: Order submission delay

​Example 2: Order update delay

​Example 3: Order cancellation delay

​Example 4: Immediate update after creation

​Fail-safe order operations

​Order filtering (intrabar_order_filter parameter)

​Manual trigger filtering: previous price comparison

​Manual trigger filtering: trigger at bar close

​Manual trigger filtering: only first trigger during bar

​intrabar_order_filter.ON_BAR_CLOSE

​intrabar_order_filter.FIRST_IN_BAR

​intrabar_order_filter.LAST_IN_BAR

​intrabar_order_filter.NO_FILTER

​How filtering applies to cancel_order and amend_order

​Price for market orders (market_order_price parameter)

​Simulation of trading at market close

​Simulation of trading at market open

​Margin trading (leverage parameter)

Backtesting vs live trading

Identical in both modes (strategy behavior)

Simulated only (backtesting)

Live only (real exchange)

Order execution

Example 1: Order submission delay

Example 2: Order update delay

Example 3: Order cancellation delay

Example 4: Immediate update after creation

Fail-safe order operations

Order filtering (`intrabar_order_filter` parameter)

Manual trigger filtering: previous price comparison

Manual trigger filtering: trigger at bar close

Manual trigger filtering: only first trigger during bar

`intrabar_order_filter.ON_BAR_CLOSE`

`intrabar_order_filter.FIRST_IN_BAR`

`intrabar_order_filter.LAST_IN_BAR`

`intrabar_order_filter.NO_FILTER`

How filtering applies to `cancel_order` and `amend_order`

Price for market orders (`market_order_price` parameter)

Simulation of trading at market close

Simulation of trading at market open

Margin trading (`leverage` parameter)