After a little community talk at trading chat I came up with two problems that were noticed (you can add more if I missed)
I would like to develop my own bot. After a look at sandbox environment I noticed that the liquidity and price action are low and not efficient to test a bot IMO. I know that at least one community bot developer do tests on production, I would rather not test it on prod. How hard it would be to implement good enough continues sandbox price action to test bots (one that might mimic current market action or pre configured looped action)?
exchange volume, That’s actually something I noticed and not actually something that team have direct influence about. It’s more towards bot creators, from what I noticed all of our community bots are more MM oriented rather than Taker oriented. So as most of out trades made through API (only a guess). I think that if more taker strategies would be implemented we might have high exchange volume.
I also tested my bot in live production. As long as you don’t really submit an order there is also no risk in loosing money. You do a lot of stuff like getting the orderbook, getting best ask, best bid, calculating when to enter a trade, when to close a trade, … Therefore, you can test your whole logic of the bot in production environment. You should log everything and compare the to initiated trades afterwards with manual calculations.
However I did lose the one or the other dollar while development. The reason were:
Didn’t do the math well enough and had failures in my logic
Used market orders instead of limit orders, which are allowed to be taker orders
I agree with your point that more taker oriented bots would increase the volume. Still there are pairs with a lack of market making bots like:
neo/eth
gunthy/btc
noia/btc
Getting these pairs more active would also could increase the volume due to different strategies.
I’m for this as well. WOuld be really great if Nash can provied sandbox environment as close to production as possible. I don’t know if data can be “passed” from production to the sandbox or not. The lag would be also fine, we just need better sandbox.
I personally believe this would also increase interest in Nash for developers and testers. I’d like to make my own bot but that one is planned to be pretty complex one. I need a lot of trades to go through it before I optimise properly. The only reason why I haven’t started is exactly this - that sandbox is not efficient and production would cost me a lot of money.
I also did my very first testing in a sandbox. I created multiple sandbox accounts and tested my logics between these accounts. But it is very hard. So later all my testing did on prod.
Yeah, it has some cost, but the main cost is only fees. If you testing with minimum order size it is not a big cost.
In cloud bot binance-arbitrage strategy is 100% taker, market-maker strategy is about 90% taker. Currently, I have limited access to market-maker bots because of low maker liquidity in exchange. So I feel we need more makers as well.
Therefore, you can test your whole logic of the bot in production environment. You should log everything and compare the to initiated trades afterwards with manual calculations.
That’s actually the exact thing I want to avoid, not even talking about the tax events that those tests make you commit.
What if you want to trade while testing your product, test strategy with massive funds ? testing with 10$,100$ on production might be “fine”, what if your code has a mistake that makes it a 10K trade? do you want to test in production strategy using 10K$?
when I use API I want to test it myself, For example let say that you execute order of 10$ but API for some reason has bug that makes it 1000$?
The API isn’t documented yet so I would rather do trail and error in a sandbox environment.
I have limited access to market-maker bots because of low maker liquidity in exchange. So I feel we need more makers as well.
I can understand this fear but at least from a taker side I don’t think bot makers actually use the option of “fill or kill”. which suppose to help in this case. at least half way.