Bug info:
A number of deals closed at a loss, without cause…
While these could have been nice profits!
And there is 1 deal that has more filled DCAs than is possible…
I understand that Gainium and/or the exchange is busy with these kinds of BTC actions, and that you sometimes don’t get orders filled as a result. But that he closes deals unnecessarily is very annoying, because this makes me miss out on nice profits, and this ruins my stats (and mood).
Thank you for reporting this issue. During the big dump on the bot’s symbol, the TP was filled before other DCA orders could be filled. This caused the bot to sell the remainder of the deal immediately, without respecting any TP levels.
What deal are you talking about? Because when I look at my deals, I can clearly see on the chart that he placed the DCA orders, and later executed a TP indiscriminately.
Also when I look at ‘Show Orders’:
(The charts are all on the 1min TF).
IDEX:
I understand that due to yesterday’s chaos the exchanges/gainium couldn’t keep up, but I don’t understand that he is closing deals while the target profit has not yet been reached. Surely that is separate from yesterday’s chaos?
If you look at my pictures you will see that for the 3 deals he finished filling the DCA orders around 22:05. And that all goes well, and suddenly the bot decides to close the deal 5 to 10 minutes later, I don’t get that?
Because in theory you would expect it to be just the opposite:
The market dips dramatically
DCA orders are filled
Since Gainium/Exchange is still busy, the old TP from before step 2 cannot be placed/moved, and is still at the old level from before the filled DCA orders.
When the coin rises again, it closes it at the TP value that has not yet changed.
With every DCA order filled, the TP order is canceled and replaced with a new one from the average price. During this process, one of the TP orders was filled, causing the deal to close unexpectedly.
We’ve identified and fixed this issue for deals with more DCA orders than intended. A similar problem was resolved in the combo bot previously, and the fix has now been applied to DCA bots. The update will be included in the next release.
So if I understand correctly.
In the background the TP orders belonging to the DCA orders are already ready in your system?
So during a quiet market you get this:
BO placed → (BO) TP is placed
DCA 1 to 20 are placed on the exchange, and the TPs belonging to the DCAs are ready to be placed in your system, if the DCA is filled.
DCA 1 is filled → (DCA1) TP is placed
TP is achieved, open DCA orders are cancelled. Deal is closed.
What happened yesterday:
BO placed → (BO) TP is placed
DCA 1 to 20 are placed on the exchange, and the TPs belonging to the DCAs are in your system ready to be placed, if the DCA is filled.
DCA 10 is filled → (DCA20) TP is placed, and it is comparatively too low. (So this is where it goes wrong)
TP is achieved too early, open DCA orders are cancelled. Deal is closed at a loss.
You’re correct in your understanding. The issue occurred when, during DCA processing, an incorrect TP (e.g., from a different DCA level) was placed instead of the correct TP for the updated average price. This caused the TP to trigger prematurely, canceling open DCA orders and closing the deal at a loss.
We’ve applied a fix to ensure only the correct TP for the updated average price is placed. This fix, already implemented in combo bots, will be included for DCA bots in the next update.
For the fact that people unnecessarily lost money because deals went into the minus when apparently it could have been prevented through a fix from your side?
Because what I have talked about before in this topic, it is understandable that the Exchange/Gainium are too busy during a hugely volatile moment of BTC. But that should not result in deals closing early, partly due to your method/technique of working with the posting of the TPs.
You can’t ask for a refund for a technical glitch any more than I can ask you for a part of your profit that you gained when there is no glitch. It says on our terms and conditions (which you need to check every time before logging in) that we are not liable for any losses. We do everything we can to prevent bugs from happening but there is always a risk with software.
We do give ocassionaly give credit, which is evaluated on a case by case basis and when loses are over $50. You can however ask for a refund on your subscription as per our refund policy.
