Dependence first order volume from PROFIT_MAX parameter, exchange rules for trade pair and trade conditions

[DogsTailFarmer]

Colored lines are calculated for different base price levels

k_m = 1 - PROFIT_MAX / 100
amount_first_grid = max(amount_min, (step_size * base_price / ((1 / k_m) - 1)) / base_price)

In a normal state, a strategy (let's say in Buy mode) has several buy orders and one sell order. The current price is between them. The closer a sell order is to the grid, the more likely it is to be filled, and it requires a smaller price change. But the profit of the cycle will be less. To adjust the profit parameter for the current cycle, the Bollinger Band indicator and two parameters that set its minimum and maximum values ​​are used - PROFIT and PROFIT_MAX

However, to calculate the volume of the first order, I need to take into account the exchange limit for the trading pair, namely stepSize defines the intervals that a quantity can be increased/decreased by

The graph above shows this relationship. If the volume of the first order is too small, the gap between the grid and TP will be too large to meet this limit. This will result in an infinite (very long) downtime for the strategy while waiting for the price to change. Therefore, the volume of the first one is calculated in such a way that when it is executed, the TP order is separated from the grid within the PROFIT_MAX limit

Keep these limitations in mind when setting the PROFIT (0.1 - 0.25) and PROFIT_MAX (0.5 - 0.85) parameters.

[DogsTailFarmer]

And the following graph demonstrates the dependence of the cycle income (assuming one grid order and TP is executed) on the value of the PROFIT_MAX parameter. Conclusion - practically does not depend. The step_size constraint and the current price are decisive.

The smaller the value of the parameter, the more effective the strategy will be in a side market. Limitation - a sufficient amount of the deposit to place the grid, taking into account the size of the first order.

[2x4ever]

I've read it many times, but I still can't figure out how the profit is related to step_size

[DogsTailFarmer]

Hi!

The short answer is I don't know.

This isn't about that.

This is an illustration of some of the dependencies found as a result of development, the abstracts are as follows:

• the step_size is a part of trade rule settings by exchange
• the larger the step_size, the larger the order volume required to obtain a given income
• the greater the given amount of income, the less likely it is to receive it

These findings became the basis for calculating the size of the first order in the grid. As a result, under certain conditions, its volume may be larger than those following it, which at first glance contradicts the idea of ​​grid orders, but increases the likelihood of TP execution.

Now the calculation has become a little more accurate, but the idea is the same.

if not additional_grid and not grid_update and not GRID_ONLY and 0 < PROFIT_MAX < 100:
            try:
                profit_max = min(PROFIT_MAX, max(PROFIT, f2d(100 * self.atr() / self.get_buffered_ticker().last_price)))
            except statistics.StatisticsError as ex:
                self.message_log(f"Can't get ATR value: {ex}, use default PROFIT value", LogLevel.WARNING)
                profit_max = PROFIT
            self.message_log(f"Profit max for first order volume is set {profit_max}%", LogLevel.DEBUG)
            k_m = 1 - profit_max / 100
            amount_first_grid = max(amount_min, (step_size * base_price / ((1 / k_m) - 1)) / base_price)
            amount_first_grid = self.round_truncate(amount_first_grid, base=True, _rounding=ROUND_CEILING)
else:
    amount_first_grid = amount_min

Regards, Jerry.

[2x4ever]

Thanks for the reply.
But I still don't understand why you limit yourself to the step_size.
The only place where it might matter is reverse_cycle, where you just can't place a take profit order closer than step_size.
But in direct cycle, the only limitation is the FEE.
For ex.:
Your first grid order in BTCUSDT pair can be as small as 5.3 USDT with 0.00019 BTC at price ~= 27894, then you can sell this 0.00019 BTC for 27986 price having 5,30081 USDT at the end with 0.00081 USDT profit with is 0.015%. step_size constraints is not involved here in any way. The only limit here is FEE.

`

   if buy_side:
         Calculate target amount for first
        self.tp_amount = self.sum_amount_first
        profit = self.set_profit(self.sum_amount_second, by_market)
        target_amount_first = self.sum_amount_first + profit * self.sum_amount_first / 100
        target_amount_first = self.round_truncate(target_amount_first, base=True, _rounding=ROUND_FLOOR)

        #i don't understand why we need this here
       
        if target_amount_first - self.tp_amount < step_size_f:
            target_amount_first = self.tp_amount + step_size_f
        
        amount = target = target_amount_first
        # Calculate depo amount in second
        amount_s = self.round_truncate(self.sum_amount_second, base=False, _rounding=ROUND_FLOOR)
        price = f2d(tcm.round_price(float(amount_s / target_amount_first), RoundingType.FLOOR))

`

Second thought: PROFIT_MAX is a limit for profit and depends only on BB, it should not be dependent on step_size
Making first order in grid bigger with smaller profit limits is counterintuitive.
Moreover, in a downtrend, this increases the chances for a cycle reversal, because a gap between TP orders and GRID will increase too much, small orders will be unable to move TP order down.

[DogsTailFarmer]

Hi!

The step_size constraint applies in any case, including in a Direct cycle. If the step_size is comparable to the size of the first grid order, then when the first grid order is executed and a TP is placed, there will be a huge GAP between the remaining grid orders and this TP. I limit the maximum GAP by the PROFIT_MAX parameter, which is used to calculate the size of the first order.

Please note - this limitation only affects for large step_size! For most pairs on binance it is small and does not affect the size of the first order.

There is another limitation on the exchange, this is MIN_NOTIONAL

For Binance, this is a stricter limit than step_size.

PROFIT_MAX is a parameter that the user sets, adjusting the probability of TP execution.

#i don't understand why we need this here
       
        if target_amount_first - self.tp_amount < step_size_f:
            target_amount_first = self.tp_amount + step_size_f

If we sell x BTC (USDT) we can buy x + step_size or more.

You can change code and try on testnet, wich available for Binance, Bitfinex and OKX.

Regards, Jerry.

[2x4ever]

Hi!
I'm sorry for the lamb questions.
If we sell x BTC (USDT) we can buy x + step_size or more.
This is true for sell cycle. But for a direct buy cycle: if we buy x BTC for y price then we can sell x BTC for y + some_diff price, and some_diff has no correlation with step_size and is limited only by FEE
Regards, Vladislav

[DogsTailFarmer]

OK, the last sentence is true. And for direct buy cycle it is not necessary to apply a limit based on step_size.

But there is another consideration; even with this limitation, the volume of the first order is a small part of the total deposit. With small price fluctuations, often only the first few grid orders are fulfilled and the greater the volume of the deposit involved in the turnover, the greater the absolute profit.

Therefore, the same method for calculating the volume of the first grid order is used for different types of cycle.

Regards, Jerry.

[DogsTailFarmer]

Hi! I'm sorry for the lamb questions. If we sell x BTC (USDT) we can buy x + step_size or more. This is true for sell cycle. But for a direct buy cycle: if we buy x BTC for y price then we can sell x BTC for y + some_diff price, and some_diff has no correlation with step_size and is limited only by FEE Regards, Vladislav

And in the general case, this is also not true, since there is also a restriction on the price step and some_diff must be a multiple of this step.

Regards, Jerry.

[2x4ever]

Is this a specifically restriction on some crypto exchanges? I removed this limitation from code and see no problem on binance.

[DogsTailFarmer]

tickSize

[2x4ever]

Thank you!
Given BTC/FDUSD pair on binance tickSize = 0.01, while step_size = 0.00001. With current price around 27800, step_size = 0,278 FDUSD, which is much bigger than tickSize.
Maybe we can modify this condition to MIN(tickSize, step_size_s) ?

[DogsTailFarmer]

I don't plan to make changes to this part yet. But you can fork strategy and change it freely to suit your needs.

And the expression MIN(tickSize, step_size_s) is incorrect in meaning - one parameter is the price step, the second is the order size step.

Regards, Jerry.

[DogsTailFarmer]

This is correct, but I don't understand the meaning MIN(tickSize, step_size_s) ...

[2x4ever]

Because we are not limited by step_size on direct cycle and limited only by tickSize we can change condition:

            if target_amount_second - self.tp_amount < step_size_s:
                target_amount_second = self.tp_amount + step_size_s

to

            if target_amount_second - self.tp_amount < tickSize:
                target_amount_second = self.tp_amount + tickSize

This will lower the gap between TP order and other grid orders
MIN(tickSize, step_size_s) not needed here, you're rightю

[DogsTailFarmer]

Oops, but do you understand that tickSize is a price change step, not volume?

[2x4ever]

Yes, we are not changing volume here, volume is constant == self.sum_amount_first
What we are calculating here is price, not volume.

[DogsTailFarmer]

Try it, it doesn't seem right to me. For direct buy cycle you can omit this path at all.

[DogsTailFarmer]

Hi! And one more consideration - for calculating TP parameters, it does not matter whether it is Direct or Reverse cycle. Buy or Sell only.

Regards, Jerry.

[2x4ever]

Hi! Thanks for consideration.
I have one also :)
Actualy in sell cycle we can omit this contraint too.
We can sell some amount and then buy the SAME amount but with smaller price.
I that case we do not increasing first currency depo, but we can decrease reverse_target_amount.

[DogsTailFarmer]

reverse_target_amount at all from another theme - it's target volume for Reverse cycle and those value is used to calculate the grid parameters of the reverse cycle - overlap range, etc. This has nothing to do with the calculation of TP inside a cycle (any).