I have a question or an Issue regarding the Feature “Required Change”.
I don’t know If I have missunderstood this feature but as of my understanding I can set up a required change for example 0.2% and the bot does calculate the DCA amount to always be 0.2% away from the TP level.
When I set up a bot with a scaled DCA and a very tight grid like 0.25% deviation for each DCA it does not adjust the volume. The volume needs to be higher with every DCA but it is always the same Volume.
Also the table shows that it’s always the same volume and therefore the TP level is increasing and not stable by 0.1%. It needs to be a logarithmic factor to always have 0.1% TP
No, the required change (to take profit) is the percentage from the current price of the currency to reach the take profit level of the deal, that is the take profit percentage away from the deal’s average price.
Unfortunately, tries to make required change to take profit and the take profit to be the same, what would require infinite funds to bring the average price to the level of the current price.
What did you expect was going to happen if you set the required change to 0.2%? Such a small required change is going to exponentially increase the funds needed on each dca.
It’s completely okay, that it’s required change (to take profit). What isn’t okay is that Gainium doesn’t allow us to configure a different value for take profit. This doesn’t mean that the required change has to be to break-even then but is just how the required change to take profit behaves mathematically! It surely cannot have the same value except when the price is exactly at the average price of the deal, which can never be achieved by safety orders but by the movement of the currency’s price.
Internally also @maksym.shamko is coping with this by choosing the required change to take profit slightly bigger than the take profit, simply because every safety order would need unlimited funds if Gainium would use the exact same value for both!
Try it yourself if you don’t trust my math and explanations. If you have a deal with e.g. 1% take profit without safety orders. The deal goes against you e.g. 5%. What is your required change to take profit now? Surely it isn’t 1% but around 6.32%.
If you add a small safety order that only changes the required change to take profit a little e.g. to 4%. If you instead add a very high amount, you surely are able to make your required change to take profit almost the same as take profit. But usually we don’t have the funds to do so and if only for a few safety orders. Then without adding any further safety orders the required change to take profit becomes bigger again, if the price continues to move against our deal. That’s why we have our red bags!
Only if the price finally approaches your 1% take profit, the required change to take profit first becomes smaller than your take profit and then even negative when the price passes your take profit level indicating that you would “require” a reversal to return to your take profit.
I don’t understand why the required change must be lower after each dca and what is the formula to calculate it. That is already how the volume scale works and you can tweak it and check in the table of the example deal what is the required change at each step.
Show me another platform that is doing what you want and I will be happy to take a look. Until then I don’t have time to discuss this topic anymore.
I gave you the formulas in my other topics. A small recap.
deal average price
= (deal's cost in quote + safety order's cost in quote)
/ (deal's size in base + safety order's size in base)
take profit price
= deal average price × take profit %
required change to take profit %
= take profit price / current price
= deal average price × take profit % / current price
<=>
required change to take profit % / take profit %
= deal average price / current price
Notice the last proportion! It says that you would have to make average price and current price to be the same if you wanted your required change to take profit to be the same as your take profit. This either can be achieved by increasing the size of the safety order astronomically or waiting until the current price matches the current price.
And regarding your time, I fully understand it. Only notice that it already took me hours if not days or even longer to write all my messages to support Gainium.
And I appreciate that. Is just that I have other things to do and I can’t engage in a discussion back and forth with you all the time.
Like I said you can add the take profit % to the desired break even. So if tp is 5% and you want a required change to break even of 10%, then you set it 15%, so that the 10% is to break even.
required change to break-even = 10.0%
take profit = 5.0%
=> required change to take profit = 15.5%
Now I want to configure it like that and configure
take profit = 5.0%
But when I also configure
required change to take profit = 15.5%
my previous configuration changes to
take profit = 15.5%
And that’s totally wrong!
We don’t want our take profit level to be 15.5% away from our deal’s average price. It should only be 5% away from it.
Required change to take profit means instead that the 5% take profit price from the average price of the deal shall be 15.5% away from the current price of the crypto currency.
Finally I understood the problem. Not so difficult to explain the problem in one sentence: “When I change the required change, the take profit changes to the same %”. Without formulas and lengthy explanations. Maksym will fix that.
This is not the best way anyway - we already discussed this - only dynamic volume makes the deal expensive for no reason - after this, I’m going to retire the topic is getting too long as usual - you would need a few words to explain everything
Maksym: I removed tp and required change dependency. Required change cannot be lower than TP, because it will require qty of DCA to be negative, it can be higher than TP, it this case amounts will be decreased, but respecting minium exchange values
Thanks a lot for your patience, time and effort. I am looking forward to test it again. Hopefully finally also my bug reports gets updated from not-bug to fixed-bug.