Very nice update and very user friendly - I haven't seen a lot of action yet but BTC prices have been pretty stagnant lately. Will keep monitoring. The major change that I have seen is that, unlike the previous MtGox, it has become impossible to make a manual trade at a price that is different than the current one - if it doesn't get executed by the time the new round of API calls are made, the manual trade gets erased.
First about manual trades getting erased. There's no feature doing that on purpose, but there are conditions triggering order cancels, regardless of their origin.
A whole "half band" (all asks or all bids) may be cancelled if:
- its span (defined by the percentage between the outer order and the central margin limit), is found smaller than the minimum configured width or higher than the maximum configured width
- the outer order value, multiplied by the "Low resource reset factor" parameter, is found higher than the corresponding available resources (btcs for asks, and usds for bids), which are computed from the total resources from removing the defined reserve and the existing open orders. You can acknowledge those quantities in your history: the last wallet balance gives your total resource, whereas the last issued orders "balance" shows the available resources at the time of the computation. Also, you can remove that "low resource reset" feature by setting that parameter to 0
Additionally, a single order may be cancelled because of the "cancel order limit" percentage parameter. That parameter was meant for exponential price distributions: it makes sure the density keeps decreasing going outwards from the ticker when the price moves: if the variation between 2 consecutive orders spans (Ask(i)-Ask(i-1)/Ask(i-1)-Ask(i-2)) is found lower than this parameter (wrongly increasing density), the outer order is cancelled. Up until recently, I had kept the 90% value, which was meant for the original exponential distribution. Now that the default distribution features a near constant linear span, I switched to 50%, but you may feel free to set that parameter to 0 to completely remove that feature if you don't need it.
Also, based on a previous post, is it fair to assume that the only way to make the bot trade bigger amounts is to increase the balances?
There are several parameters responsible for defining the order amounts:
- The outer orders are defined as a percentage of the available resources (btcs for highest ask, usds for lowest bid): the corresponding parameter is "Default Max Order(%)". "Default" means that at any point you can update such an outer order manually, making sure you don't trigger an "half band cancel" as explained above
- Then the inner orders amounts are computed from the corresponding arithmetic expression. The default expression plots a linear variation in value between the outer order value and the central margin boundaries limit, the value of which is also defined as a percentage of the outer order with the "Min Order Value (%)" parameter
- You may update the dynamic amount expression to your needs, but if you choose to stick with the default value, the constraint mainly resides in the price distribution.
- If you choose to define a large trading band with many inner orders (as with the current default strategy), you'll have to keep everything pretty low: the bot won't let you issue orders that aren't provisioned, and will fit everything accordingly; also, there is a minimum order on each exchange platform (0.01 btcs on MtGox), which could result in central orders not being issued if you're low on resources. Accordingly, if you want higher amounts, you'll need to issue less orders, by narrowing the band or by changing the order distribution (by choosing a larger or a varying step e.g exponential).
- One thing to consider though if you change the distribution, is the density near the central margin: As far as I can tell, you can't have both a large order step near the ticker and a narrow central margin, while reliably earning on small oscillations (which honestly I'm starting to consider as negligible considering the all-or-nothing kind of volatility we have). Anyway, in order to get the appropriate behavior with low volatility, you have to make sure the central step is smaller than the configured margin.
I hope all of this makes sense. I understand it may look over-complicated, but it is just the result of identifying the various possibilities over the last months, given a simple algorithm, and making them available to the users.
Now I'm all open to trying something completely different. As a matter of fact, I have added a c# project to the source code, with a simple alternate strategy that shows how to get started. If you think you can come out with something better, please let me know, and I'll be happy to add it to the hosted platform.
The only thing is I'd like to keep the free platform hosting market making bots: I reckon there are quite a few tools that amplify the trends out there, and that providing liquidity should be beneficial to the whole community.
I realize it can be frustrating when given the current strategy, the price variation exceeds the trading band configured for many, resulting in a loss, but I'm sure we can find a compromise where those situations are properly accounted for (for now, I have increased the default band width), and the profit fairly shared among all.
If you're up for a predictive strategy that works with the trend, feel free to go for it and to get your bot a private hosting (which we can provide, and I'll update the source package with a version fully compatible with DNN 6.X shortly). There are good chances you'll want to keep it personal anyway.
Now if you are concerned with price stability, you're more than welcome helping us improving the public platform. As a matter of fact, I don't think there is much "secret" involved with such strategies, which is the reason I made the results public. The gains will reduce only if we're so successful to reduce the volatility substantially, which for many reasons I don't see happening any time soon.
Finally I should say I won't be able to invest much more in here for free. One possibility is that we propose a commercial version with a faster pace and other enhancements. We're thinking about it.
Also, if you're thinking of an opportunity for a collaboration, please let us know.
Regards,
Jesse
CTO Aricie
