I think this has happened after an update in the last month or so, I realized my bots other than BTCUSD and ETHUSD cannot trade most of the time. When I debugged the XLMUSD bot I saw this:
DEBUG QE [A] 4:4 {"ask":{"price":0.135479,"size":87.96717179033301},"bid":{"price":0.135322,"size":11.229851717914853}}.
see them weird sizes? https://api.pro.coinbase.com/products states clearly that {"id":"XLM-USD","base_currency":"XLM","quote_currency":"USD","base_min_size":"1","base_max_size":"600000","base_increment":"1"
thus these orders with such fractional sizes automatically get rejected. any idea how to respect it
on step [A] the sizes are still unrounded (so that many decimals are expected); because sizes are rounded at step [I]:
https://github.com/ctubio/Krypto-trading-bot/blob/352db3e1d3c51c82f771b82790e8dbba18d89c40/src/lib/Krypto.ninja-user.h#L2200
consider to show the full debug of a quote from step [?] to [!] (including all letters in between) if you still consider that there is an issue here (i would say rounding of sizes is OK :S)
Thanks for the quick reply as always Carles, here's a whole order process. I always thought those from A to ! were separate bullets :-D
06/02 18:46:58.530569 DEBUG QE [?] 4:4 {"ask":{"price":0.136579,"size":13880.565919682012},"bid":{"price":0.136244,"size":13880.565919682012}}.
06/02 18:46:58.530598 DEBUG QE [A] 4:4 {"ask":{"price":0.136579,"size":13880.565919682012},"bid":{"price":0.136244,"size":13880.565919682012}}.
06/02 18:46:58.530617 DEBUG QE [B] 4:4 {"ask":{"price":0.136579,"size":13880.565919682012},"bid":{"price":0.136244,"size":13880.565919682012}}.
06/02 18:46:58.530632 DEBUG QE [C] 4:6 {"ask":{"price":0.0},"bid":{"price":0.136244,"size":13880.565919682012}}.
06/02 18:46:58.530647 DEBUG QE [D] 4:6 {"ask":{"price":0.0},"bid":{"price":0.13562026749952133,"size":13880.565919682012}}.
06/02 18:46:58.530663 DEBUG QE [E] 4:6 {"ask":{"price":0.0},"bid":{"price":0.13562026749952133,"size":13880.565919682012}}.
06/02 18:46:58.530680 DEBUG QE [F] 4:6 {"ask":{"price":0.0},"bid":{"price":0.13562026749952133,"size":13880.565919682012}}.
06/02 18:46:58.530694 DEBUG QE [G] 4:6 {"ask":{"price":0.0},"bid":{"price":0.135464,"size":13880.565919682012}}.
06/02 18:46:58.530709 DEBUG QE [H] 4:6 {"ask":{"price":0.0},"bid":{"price":0.135464,"size":13880.565919682012}}.
06/02 18:46:58.530724 DEBUG QE [I] 4:6 {"ask":{"price":0.0},"bid":{"price":0.135464,"size":13880.565919682012}}.
06/02 18:46:58.530741 DEBUG QE [J] 4:6 {"ask":{"price":0.0},"bid":{"price":0.135464,"size":13880.56591968}}.
06/02 18:46:58.530767 DEBUG QE [K] 4:6 {"ask":{"price":0.0},"bid":{"price":0.135464,"size":13880.56591968}}.
06/02 18:46:58.530781 DEBUG QE [L] 4:6 {"ask":{"price":0.0},"bid":{"price":0.135464,"size":13880.56591968}}.
06/02 18:46:58.530797 DEBUG QE [!] 4:11 {"ask":{"price":0.0},"bid":{"price":0.135464,"size":13880.56591968}}.
06/02 18:46:58.530845 DEBUG COINBASE <<< {"order_id":"be7ff8e6-53cc-4bb2-b075-54f203e300cc","price":"0.13657900","product_id":"XLM-USD","reason":"canceled","remaining_size":"2000.00000000","sequence":109784281,"side":"sell","time":"2019-06-02T22:46:58.318000Z","type":"done"}.
Does this look alright you think? I still don't think it can give orders.
im sorry it may be more usefull --debug-orders argument, because it shows when an order is send and if the order is canceled or accepted (your logs about calculated quote steps looks OK i would say)
can you share the logs but including as well as the quote debug msgs, the order debug msgs of at leat one quote/order that you suspect?
thank you'''
06/03 10:53:51.161310 DEBUG OG saved bd45546d-969d-4b56-8000-0064617b3002:: [0]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.161360 DEBUG OG memory 1.
06/03 10:53:51.186615 DEBUG OG reply bd45546d-969d-4b56-8000-0064617b3002::3d4b9e88-c03f-42bc-8d73-367fb311a812 [2]: 0.00000000 XLM at price 0.000000 USD.
06/03 10:53:51.186661 DEBUG OG saved bd45546d-969d-4b56-8000-0064617b3002::3d4b9e88-c03f-42bc-8d73-367fb311a812 [2]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.186678 DEBUG OG memory 1.
06/03 10:53:51.186696 DEBUG OG purge bd45546d-969d-4b56-8000-0064617b3002::3d4b9e88-c03f-42bc-8d73-367fb311a812 [2]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.186710 DEBUG OG memory 0.
06/03 10:53:51.220817 DEBUG OG saved 2ad17d34-5d5e-4d60-8000-00764f7377c0:: [0]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.220854 DEBUG OG memory 1.
06/03 10:53:51.241276 DEBUG OG reply 2ad17d34-5d5e-4d60-8000-00764f7377c0::05522ce8-cd07-4d8a-9845-fbb79d27ad72 [2]: 0.00000000 XLM at price 0.000000 USD.
06/03 10:53:51.241314 DEBUG OG saved 2ad17d34-5d5e-4d60-8000-00764f7377c0::05522ce8-cd07-4d8a-9845-fbb79d27ad72 [2]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.241330 DEBUG OG memory 1.
06/03 10:53:51.241347 DEBUG OG purge 2ad17d34-5d5e-4d60-8000-00764f7377c0::05522ce8-cd07-4d8a-9845-fbb79d27ad72 [2]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.241361 DEBUG OG memory 0.
06/03 10:53:51.323370 DEBUG OG saved d8a1063a-13c0-4aeb-8000-008b231198ea:: [0]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.323412 DEBUG OG memory 1.
06/03 10:53:51.343854 DEBUG OG reply d8a1063a-13c0-4aeb-8000-008b231198ea::ee37d98b-1112-435f-8bc2-09def2a2cf5a [2]: 0.00000000 XLM at price 0.000000 USD.
06/03 10:53:51.343896 DEBUG OG saved d8a1063a-13c0-4aeb-8000-008b231198ea::ee37d98b-1112-435f-8bc2-09def2a2cf5a [2]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.343913 DEBUG OG memory 1.
06/03 10:53:51.343933 DEBUG OG purge d8a1063a-13c0-4aeb-8000-008b231198ea::ee37d98b-1112-435f-8bc2-09def2a2cf5a [2]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.343947 DEBUG OG memory 0.
06/03 10:53:51.470115 DEBUG OG saved 41db3c68-4d16-40ce-8000-00e52ce9a561:: [0]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.470165 DEBUG OG memory 1.
06/03 10:53:51.490566 DEBUG OG reply 41db3c68-4d16-40ce-8000-00e52ce9a561::3baab77e-68fb-4495-a4ce-5b346bda6a02 [2]: 0.00000000 XLM at price 0.000000 USD.
06/03 10:53:51.490609 DEBUG OG saved 41db3c68-4d16-40ce-8000-00e52ce9a561::3baab77e-68fb-4495-a4ce-5b346bda6a02 [2]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.490626 DEBUG OG memory 1.
06/03 10:53:51.490646 DEBUG OG purge 41db3c68-4d16-40ce-8000-00e52ce9a561::3baab77e-68fb-4495-a4ce-5b346bda6a02 [2]: 15506.95719651 XLM at price 0.129751 USD.
06/03 10:53:51.490660 DEBUG OG memory 0.
06/03 10:53:51.519340 DEBUG OG saved 6ab25fd3-29ef-4087-8000-00b880aec2d7:: [0]: 15506.95719651 XLM at price 0.130003 USD.
06/03 10:53:51.519375 DEBUG OG memory 1.
06/03 10:53:51.539703 DEBUG OG reply 6ab25fd3-29ef-4087-8000-00b880aec2d7::acbf6ba0-df7b-4934-be22-4666526cf91e [2]: 0.00000000 XLM at price 0.000000 USD.
06/03 10:53:51.539746 DEBUG OG saved 6ab25fd3-29ef-4087-8000-00b880aec2d7::acbf6ba0-df7b-4934-be22-4666526cf91e [2]: 15506.95719651 XLM at price 0.130003 USD.
06/03 10:53:51.539763 DEBUG OG memory 1.
06/03 10:53:51.539779 DEBUG OG purge 6ab25fd3-29ef-4087-8000-00b880aec2d7::acbf6ba0-df7b-4934-be22-4666526cf91e [2]: 15506.95719651 XLM at price 0.130003 USD.
06/03 10:53:51.539793 DEBUG OG memory 0.
see them fractional orders :disappointed: appreciate your valuable time as always.
many thanks for the lovely logs''''
yea seems there is an issue there cos reply [2] is not nice (means canceled right away without even placing the order in the book; that is OK only if not enough funds)
let me look at it more slowly and come back againz'隆 (ima try to reproduce it somehow with all your infos; thanks'隆)
we have a mess of mininum quantity size and quantity increment; using both as one, when really they are two :S or using just one and wrongly calculating the other
will fix but require super testing of all markets :dancer: appreciate your patience'隆
price increment is nice as-is; but could be called price tick instead of min tick to avoid confusions with the missing quantity increment (that may be missing currently because of the current naming confusion :D)
for example, btc/usd should be:
that is 3 variables, not 2 as we currently have:
the quanitty of tick matches for BTC markets to 0.00000001, but XLM markets should be 1, so the hardcoded 0.00000001 doesn't helps much
on XLM/USD for example, should be:
but we currently have:
(here we have 8 decimal places more than required because of the hardcoded dummy calculation of quantity tick)
we are also missing max quantity size, but doesnt seems so critical thiz one
陌sn't the quantity tick provided by coinbase API, how about we read that instead of hardcoding?
I remember we had the opposite issue for poloniex where it wasn't provided by the API so we had to hardcode it but what can we do :laugh:
yea is exactly as you said, we need to properly fix it for once and all exchanges instead of the dummy hardcoded fix coming from other exchanges that is affecting coinbase xD (i didnt noticed cos im mainly on BTC and EUR markets and i dont use % often)
so, just read the API value for coinbase/hitbtc and calculate it (hardcoded calc of 8 or 10 decimals as-is now) for others; seems like a plan :D thanks'隆
:koala: Thank you for helping me help you help us all.