Using branch 4.x:
After receiving response "funds on hold" during a buy or a sell the bot will stop trading till a new trigger.

Also this error causes it to stop trading as well.

I am getting this too. I feel like its when I am running very aggressive EMA e.g. 1m, 10, 9 ...
My simulations all shown gainz. But real trading shows loss POSSIBLY because of these errors and unfilled trades.
I should note I am ETH/USD on Gdax.
Running a sim shows about 50-60 trades a day with good returns. Live Trading return is much lower due to trading times and errors for me. My sim are more closer to reality when i set the delay on transaction to 60 or 70 secs.
which option is the trading delay? in main Conf or strategy?
zenbot sim --order_adjust_time XXXXXms
Ah, thanks was just looking in sim.js for it
:)
No problem at all
Well that definitely matches real trading more closely. Now to figure out a strategy that beats hold with 60 sec delay... ug.
Anything that can increase the trading speed in this app would be a huge help imo. I was thinking if it makes more sense to do many micro-transactions or short poll times and relisting. Still trying to figure it out.
Same, we should start a slack... although many people (unlike our beloved carlos) may be un willing to share.
I would do that
The funds on hold issue, I'll probably "fix" by continuing to poll the balance until a new signal shows up. Giving up after 2 tries seemed ok when the system was spitting out tons of signals, but now I've limited signals to just the first period of a trend so missing a signal can be a big deal.
I feel like its when I am running very aggressive EMA e.g. 1m, 10, 9 ...
My simulations all shown gainz. But real trading shows loss POSSIBLY because of these errors and unfilled trades.
Let me know what other errors you're seeing. I experimented with 1m period too, and although it did make huge simulated profits, I think they are artificially inflated by the perfect environment of a sim. There are things the sim doesn't model and can't predict, such as
When trade rate in the sim is high, small over-efficiencies like this add up to inflate the profit by a lot. So far I feel that 1h period for Bitcoin and 15m for altcoins are working best in both practice and sim.
My sim are more closer to reality when i set the delay on transaction to 60 or 70 secs.
@Raslin777 why do you think doubling the wait period helps? In my experience at certain critical times, zenbot will place an order at bid and then almost immediately the bid will go up and a 10BTC wall will be set there, extending execution time by a lot. So that's why I see quick re-ordering to be helpful, and maybe the re-order should "jump" the wall by outbidding it by 1 increment as long as it's within the spread...
funds on hold issue should be better after 4bdb6c6d74504502ceef4c52c4fdc8b84c2c791a , will now poll every minute to see if funds are back
Awesome Carlos. Thanks so much. I will see if I can update my installed code... (I installed from downloaded zip rather than git clone)
Hi Carlos, just wanted to start off saying thank you for sharing this awesome app. This reason why I add the delay to my sim is because it's rare that a order executes immediately(typically 30s or above). I do see what your saying about hitting a wall and that can be the reason for some of the delays. The other reason is sometimes the value is increasing fast or decreasing fast and my order price is stale and is lower on the order book, by having a shorter poll time could move me up quicker. But in contrast by canceling the order and relisting it hurts my fulfilment when I'm in queue in a wall. I'm just trying to think of ways get the orders to complete faster as the logic of the bot works as per sims, it just the real time factors related to orders causing issues. I will test out the above commit and report back if there are any issues. Thank you again!
You're welcome, glad you're getting something out it!
I understand, those are all situations I've thought about. I thought maybe analyzing the order book would help, but it's hard to determine anything objective out of a constantly shifting set of orders. I might add some "jump the wall" logic instead of going with current bid/ask, but there's no guarantee it would help. Every exchange will have different conditions, which is why I make order_adjust_time configurable.
By the way, I'm going to tag 4.0 soon so the community can test it (and since I haven't supported 3.x since last fall, lol). I originally planned a web UI with graphing and log viewing, but I'll put that off for a point release.
Sounds great Carlos, if I think of anything I will test it out and update you. Thanks you again for all your hard work.