Discussion: Multiple entry or exit orders strategy management stategy interface

[Axel-CH]

Describe the enhancement

For the moment, freqtrade give users the possibility to enter or exit a trade at customized price.
The framework also provide the possibility to adjust the trade position size during the trade.
However it is not yet possible to split entries or exits between multiple orders on exchange.

As freqtrade base code is getting more mature, now allowing management of multiple orders.
It could be the moment to discuss about:
An interface that will provide more flexibility to users for entry or exit strategy, at an order level, like splitting entries between multiple order prices and quantity or event type.

As orders are already on exchange, this entry and exit method give multiple benefits:
The users will benefits of lower trading fees (market maker)
The orders have more chances to be filled, even in case of quick market move.

Explain the enhancement you would like

Multiple entry or exit orders strategy management strategy interface

custom_entry_method and custom_exit_method
Return an array of dictionaries containing orders with custom type, price and quantity.

Using it potentially disable "custom_entry_price" of "custom_exit_price" and "adjust_trade_position".

! Warning!
Make sure that total order quantity is equal or lower than what stake and leverage allow from strategy.

def custom_entry_method(trade, stake, leverage, proposed_price, enter_tag):
[
  {"order_type": "limit", "price": 23.45, "quantity": 2},
  {"order_type": "limit", "price": 23.40, "quantity": 4},
]

def custom_exit_method(trade, proposed_price, exit_tag):
[
  {"order_type": "limit", "price": 26.45, "quantity": 2},
  {"order_type": "limit", "price": 30.40, "quantity": 4},
]

Order type will be limited to "limit" first, other types like "conditional" (stop entry) may be available in future updates.

Solve: #7499

[xmatthias]

I don't see how this relates to #7499 - not at all, actually.

an early placed limit order must be placed in the orderbook (above current price for sell orders, below for buy orders).
#7499 specifically talks about conditional order support - which is something different than simply placing a limit order early.

---

for custom_entry_method - this would only ever be called one you're already in a position - either for position adjustments only, or (maybe) only if an entry signal triggered, in a similar position than custom_entry_price).

Calling it while not in a position (independent of a signal) will kill backtesting performance (if the user is not careful, also live performance), as you'll need to call it for every candle - for every pair - which we intentionally do not in backtesting to keep it reasonably fast in most cases.

I don't see why we need such callbacks split (you can provide a direction, really).

---

total order quantity is equal or lower than what stake

I don't really see how you would check this.
While a user can do configurations - custom_stake_amount() can override that with ease - and the only thing we really check in that case is if it's an allowed order (you've got sufficient stake to place the order).

---

now allowing management of multiple orders.

now this seems a bit premature. 😆
Multiple parallel orders are not supported currently - and the PR porposal is little more than a test case without actual code changes - at least for now.
That effectively means that it's based on non-existing feature - one that may be off weeks, months, or even years - depending on the progress of that feature.
I also expect that PR to have a pretty long test phase, as we'll need to make sure it's not leaving orders behind, which we really only can do by performing tons of trades across different exchanges in different scenarios / strategies.

I don't expect to think more about this issue before the groundwork for it has been done though - as it's really pointless dreaming based on an implementation that may or may not work (not all PR's work out the way we intended) :)

[Axel-CH]

I was thinking it could be related to #7499 if instead of putting limit order user put a conditional one in function output.

---

for custom_entry_method - this would only ever be called one you're already in a position - either for position adjustments only, or (maybe) only if an entry signal triggered, in a similar position than custom_entry_price).

Exactly, i'm agree with that.

Calling it while not in a position (independent of a signal) will kill backtesting performance (if the user is not careful, also live performance), as you'll need to call it for every candle - for every pair - which we intentionally do not in backtesting to keep it reasonably fast in most cases.

Understood

I don't see why we need such callbacks split (you can provide a direction, really).

I get it, it is just that the limitation that I would like to avoid is the obligation to choose entry or exit. for exemple with the current implementation of "adjust_trade_position" user need to choose if he want to increase or decrease his position size.
He can't do both at the same time and that could be limiting for some strategies using custom order prices.

In our case instead of calling custom_entry_method or custom_exit_method, It could be custom_orders

total order quantity is equal or lower than what stake

I don't really see how you would check this.
While a user can do configurations - custom_stake_amount() can override that with ease - and the only thing we really check in that case is if it's an allowed order (you've got sufficient stake to place the order).

It is just an idea to prevent users to blow up their accounts, with this feature they can manage orders directly, so things can go south really quick. But I guess this feature will be for advanced use cases, for people who know what they are doing…

now allowing management of multiple orders.
now this seems a bit premature. 😆
Multiple parallel orders are not supported currently - and the PR proposal is little more than a test case without actual code changes - at least for now.
That effectively means that it's based on non-existing feature - one that may be off weeks, months, or even years - depending on the progress of that feature.
I also expect that PR to have a pretty long test phase, as we'll need to make sure it's not leaving orders behind, which we really only can do by performing tons of trades across different exchanges in different scenarios / strategies.

I know that there is still work to do, but sometimes it is a good idea to discuss and make an agreement on long term objectives before going further, it can save time.