Aricie: Announcing a new trading bots platform

[Aricie]

Hi,

I've been using your bot for a couple of months and I have a question. Is it possible to change the code so that the gap between bids and asks is always at least 2 * (profit_margin + trading_fee).

For example, at the moment you might have a highest bid of 6.399 and the last price is 6.40. At this point, (if I understand correctly) the bot will generate asks down to 6.40 + profit_margin + trading_fee.

If we assume the trading fees are 0.5% and the profit margin is also 0.5%, the lowest ask could be at 6.464.

This means that the gap between bids and asks is too small. If the bot then executes a buy at 6.399 it could sell at 6.464 which after fees is 0.015% profit instead of the 0.5% specified. If your profit margin is set to less than the trading fees, you would be trading at a loss.

To get the profit margin that you have set in the parameters, the bot could use something like

MAX(last_price, highest_bid * 1 + (2 * profit_margin + 2 * trading_fee)) for asks and

MIN(last_price, lowest_ask * 1 - (2 * profit_margin + 2 * trading_fee)) for bids

As it is I have had to set the trading fees and profit margin much higher to compensate.

Hi Pteppic,

I think your remark is valid, and so is the fact that we should avoid the same kind of orders being issued and executed several times in a row when the price spikes before returning to the previous value between successive bot runs.

I'll take both issues in account in the updated version to come, but in the mean time I highly suggest that indeed you take a comfortable margin, and you adjust your outer orders manually when needed.

Regards

[Aricie]

To get the profit margin that you have set in the parameters, the bot could use something like

MAX(last_price, highest_bid * 1 + (2 * profit_margin + 2 * trading_fee)) for asks and

MIN(last_price, lowest_ask * 1 - (2 * profit_margin + 2 * trading_fee)) for bids

As it is I have had to set the trading fees and profit margin much higher to compensate.

Hi again,

I am about to upgrade the platform, and while I have tested your suggestion, it seems to make it worse: If you set a full margin on the existing highest_bid for the new lowest_ask, that margin  is "removed" when the bid gets executed, and depending on the other parameters, you find yourself at best with the previous half margin formula, and at worse with a new ask lower than the previously highest bid.

Anyway, I'm making it an optional parameter so that you can do you own tests with your bot.

In any case, I couldn't think of a satisfactory solution, without looking up the previously executed orders, which is not planned for this release, preventing the bot from placing orders out of phase with small oscillations as those occurring right now (placing asks on lows and bids on highs). Given the way the new orders fill the left "holes" in the distribution, it's currently a matter of chance that those holes correspond to the highs or lows of the oscillations.

In the mean time, I believe that securing a comfortable margin fixes that issue, and that the other fixes should bring an improvement (like the one preventing several series of orders of the same kind to be issued)

Let me know if you can think of a possible improvement.

Cheers

[Pteppic]

Hi,

Thanks for getting back to me.

I think I can see what you are getting at and on reflection, I don't think you can solve the problem using the max(last_price, highest_bid + margin) approach, so that option is probably not worth keeping.

I have also spotted kind of a related problem with the existing version.

During the big bitcoinica spike last week all my close in buy orders were triggered and the price continued to go down, so you start to get bigger and bigger gaps between orders. For example, say I had bids at $6.10 and $5.50 the buy at $6.10 was triggered, and the price went down to $5.60 and stayed at a similar level.

Based on the last price, the bot would generate sell orders down to $5.60 plus margin, so you could end up buying at $6.10 then selling at $5.65.

I think looking at previous executed orders is going to be the best long-term solution, so its good to hear that it is in the pipeline. You guys are doing great work!

[kdf]

Hello,

I have switched to the new platform and it seems more user friendly and secure.  But I do have a few questions.  On the old platform you could set the minimum order amount.  So for example it currently has the smallest order at .08 btc.  On the old system I could control what the smallest amount ordered would be.  How do I do that on the new system?

Another question is that with the new system I have about 44 - 51 orders set up on the old system I would have had about 12 - 18 orders at any one time.  I am assuming it is a larger number of orders because the minimum order is so small and that is the starting point.

Thanks for any help someone may be able to give.

Thanks,

[Aricie]

Hi Ken,

the minimum order amount is part of the Exchange parameters: it is the minimum order amount accepted by the exchange (i.e .01 btcs on MtGox and $1 on Tradehill).
Apart from the custom commission, which I made part of your new credentials settings, the exchange parameters are the same for all users.
Accordingly, I chose to remove the corresponding parameter from the set available for customization (but you can still browse a read-only version of it in the bot definition).

As for the number of orders issued, the default strategy was changed, and more specifically the price distribution expressions. This is because the old strategy quickly proved unfitted to the new trading dynamics.
You can have a look at the info page for more details on the recent changes.

Cheers

[malavita]

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.

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?

So far, so good, though - some of the new features are very nice


Thanks!!!!

[talpan]

Hey,

I can't change my bot settings anymore, the "save bot" button isn't there anymore.
thx for keeping this up and running

sorry, it's my fault: had checked that "view" options in the upper left corner

[talpan]

Hey again,

now it's for sure: I can't edit my bot and there is now view/edit selection in the upper left corner.

[Aricie]

Hey again,

now it's for sure: I can't edit my bot and there is now view/edit selection in the upper left corner.

Hi Talpan, I tried to hide the control panel in the site settings to remove the confusion, but apparently your user account might have some problem with that thing.
I just reset the default settings, so your should see the control panel again.
Anyway, I will upgrade to the latest DNN version. Hopefully it should fix those kind of bugs.

Regards,

Jesse

[talpan]

Thx for the fast reply but as it seems I don't have a "save-bot" button.

And thx again for the good support and this opportunity

kind regards, talpan

[Aricie]

Thx for the fast reply but as it seems I don't have a "save-bot" button.

And thx again for the good support and this opportunity

kind regards, talpan

I just checked your account, and as you had previously noted, the "view" option was checked in the top control panel. I just switched your account to "Edit" mode.
I'm sorry you guys get annoyed with that stupid "feature". Edit/View/Design mode are meant for site admins to figure out various renderings while editing the content.
I made the module such that only authorized module editor roles can save a bot instance while simple viewers such as anonymous clients can only browse the configuration. For some reason, module editors get offered that control panel by default, but there's an option to remove that.
Please let me know if you get the Edit mode properly configured now, and I'll remove the control panel for good.

Cheers

[talpan]

Now the edit-mode is checked and I have the save-bot button

Thank you very much

kind regards, talpan

[Aricie]

Just realized one post remained unanswered.

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

[schnell]

What's the minimum amount of btc/usd I can deposit to try it out, would you say? This looks interesting

[Aricie]

What's the minimum amount of btc/usd I can deposit to try it out, would you say? This looks interesting

Hi,
As I suggested above, it depends on your strategy.
The default strategy issues more than 20 ask/bid orders from about 5% of your resources for the highest to about 10% of those 5% for the lowest (closer to the current price).
Accordingly, if you have less than a couple of BTCs to get started, the default strategy will prevent central orders to be issued because of the 0.01 btc MtGox limit.

Now if you want to start with fewer resources (say X btcs), you can set your own strategy (check the "prevent overwrites" checkbox first):

• In the "trading band" tab, update the "Default Max Order" (a) and "Min Order Value" (b) such as X *80% * a% * b% > 0.01 (there is a 20% reserve by default)
• Now the problem is the corresponding band would require more resources because of the many orders, so you have to change the distribution in the expression tab in order to get fewer orders issued (you can also reduce the trading band width). If you go for an exponential distribution, that might be it.
• If you want to keep a near constant larger step say for instance "Min Ask Order Price" = LowestAsk.price * 95 / 100 and "Max Bid Order Price" = HighestBid.price * 100/95, you should take my above advice concerning central margin into consideration and increase the "Min Order Margin" parameter
• Finally, you should account for the parameters in the "order updates" tab (mainly "Low Resource Reset Factor" and "Volume Increase Factor") so that your default band doesn't get cancelled once every 2 run nor slightly increased for a while. You don't have to get it right straight away, and you can monitor your history to figure out what's going on regarding those updates (your history will tell you what your available resources are, once the bands are defined).

Cheers

Edit: fixed an error in the expressions

[malavita]

Just realized one post remained unanswered.

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

Wow, very informative, as usual - thanks Jesse!!

I vouch for the excellent product & superior support you offer - should you go the commercial route you can count me in as a customer.

Now I have to go study and come up with the best strategy


Cheers!

[evolve]

I have a quick question...I started my v2 mtgox bot and deleted the legacy bot (or tried to), but I think the legacy bot is still trading..could you check my bots (evolve) and confirm that I have the legacy bot disabled/deleted properly?

Thanks again, the new update is great!
 

[Aricie]

I have a quick question...I started my v2 mtgox bot and deleted the legacy bot (or tried to), but I think the legacy bot is still trading..could you check my bots (evolve) and confirm that I have the legacy bot disabled/deleted properly?

Thanks again, the new update is great!
 

Just checked and indeed the legacy bot was still running. I disabled your original bot, which should make it.
There must be something wrong with the delete feature again. I suspect something broken in the DNN personalization API on that specific version, since I'm pretty sure I tested that feature recently.
Well, moving on to upgrading to last DNN 6 version.

Cheers

[evolve]

Thanks for the quick fix! 

[zapeta]

I've gotten a couple emails today saying the following:

The Exchange site responds to your bot with an "invalid credentials" message.

You bot was disabled. Please check your Bot Settings.

I've done that and my credentials are correct and have been working now for several weeks.  I was just curious if there is a problem on your end somewhere.

Thanks!