3. Overriding buy_bracket and sell_bracket
For code/output blocks: Use ``` (aka backtick or grave accent) in a single line before and after the block. See: http://commonmark.org/help/

Overriding buy_bracket and sell_bracket

  • K

    I am developing a custom broker implementation.

    When you call the strategy buy and sell methods then the calls are deferred to the selected broker corresponding definitions.

    However, the same behaviour is not observed for buy_bracket and sell_bracket orders.
    The logic is complex enough for the exchange I am using that raw bracket orders cannot be detected away from normal parent-child orders. So overriding it is necessary in this case.

    0
    B
     1 Reply
  • B
    administrators

    @xterminator said in Overriding buy_bracket and sell_bracket:

    However, the same behaviour is not observed for buy_bracket and sell_bracket orders.

    You may want to elaborate, because buy_bracket and sell_bracket end up calling buy and sell. It is difficult to imagine how the calls don't end up going to the broker.

    0
  • K

    I am developing a broker for BitMEX.

    Oanda supports bracket orders using a single order with added stopside/takeside option in the main order. In BitMEX one has to create 3 separate orders just like how Backtrader operates internally.

    However, that adds some challenge. Suppose the buy_bracket was for 10,000 contracts but only 5,000 got filled because of highly volatile nature of crypto. The stopside/takeside will have the original 10,000 size and this can cause unexpected behaviour when triggered.

    In the BitMEX API, one can attach a tag "ReduceOnly" to order args. This makes sure that the order when executed only decreases your position size. This makes it possible to solve the above challenge.

    I considered that if buy_bracket/sell_bracket can be overridden than I can just attach a tag to the order identifying it as bracket and add "ReduceOnly" tag in the store.

    Another option is to use the "ReduceOnly" tag for all orders which are children. Since bracket order has 2 children, this will effectively make sure that the stopside/takeside children orders only decrease the current position.

    But I am considering that some people may not only use parent-child orders for brackets. Suppose someone has 3 buy orders linked together in a parent-child relationship. They may want the other 2 buy orders to be executed only once the first main order has been executed. One generally does this manually in BitMEX when the crypto price approaches liquidation price. They may add more buy orders for a long position so that liquidation distance is further increased. In such a case, "ReduceOnly" will beat the purpose.

    To solve this scenario, now I am considering to use some heuristics to tag order as Bracket. Heuristic rules:

    1. The order has 2 children.
    2. Both child orders have the same direction but different than the parent.
    3. There is a child whose price is higher than the parent, identifying it as takeside.
    4. There is a child whose price is lower than the parent, identifying it as stopside.
    5. Tag the order as bracket.
    0
  • K

    Do you think a better approach might be possible?

    0
  • B
    administrators

    These are complex and broker-dependent behaviors. There isn't really a better/worse approach, but the one that does what better suits you when working with such a broker

    1