Now I use a 0.0035 offset with a 0.15 tx fee which makes a 1% spread (0.0035 + 0.0015 + 0.0035 + 0.0015 = 0.01). To make a 0.5% spread, I will change both offset values to 0.001.
So you are at more or less break-even (including the pool compensation) at a SAF (spread after fees) of 1%?
What tolerance do you have configured (before orders get moved) at 0.0035 offset and what will be the tolerance at 0.001 offset?
I added the following clause to the motion:
Thank you! That’s game-changing to get it in my data feed 
I recommend to consider including a backup plan that allows you to switch back to a spread of 1% while forfeiting the 3% compensation, if the trading situation gets dire and you feel increasing the spread could help.
I mean, you guarantee to keep the orders up no matter what. Such a backup plan seems warranted.
1 Like
Here it is:
Voting has begun. The motion hash is 29d364f8677c7c955d423747fcf5005fd00f2e6b
Please have a look at the ninjaedit of my last post…
So far I am up 1.86% at a 1% spread before fees.
I don’t see a tolerance setting. I thought the tolerance was a composite of the offset and tx fees. Am I mistaken?
Isn’t there a tolerance setting in the NuBot config?
ALPv2 is based on NuBot, right?
Oh man, I’m lost. I only know NuBot from operating gateways…
Maybe @woolly_sammoth can help here?
Are you certain that an offset of 0.001 will not result in collisions with others running nubot? Because that will drastically lower your NAV.
Is there ever a point in time with 0.001 offset when a buy order you have on the books is at a higher price than the price feed? Because if this were pybot you’d definately have collisions at that offset.
1 Like
I have no idea.
What is the minimum offset that will not result in collisions?
Depends on who you ask i suppose. I usually talk about deviation of 0.25% and that an offset equal to half the deviation will result in collisions. That’s my model of it, i dont even know if 0.25% is what’s used in nubot though (my analysis comes from using pybot in alp v1). @willy might know.
1 Like
Does this mean your recommendation would be to get comfortably above 0.00125 then? Such as 0.0015?
Sure. There’s a txn fee going on inside the bot too, so im really just not sure about it all. But yah, I’d say that 0.0015 offset would give me confidence that your operation will not have NAV lowered by collisions with other instances of nubot run by other operators.
Based on your recommendation I just altered to the motion to specify a 0.6% spread, which will be done by setting the offsets to 0.0015 just as you suggested.
Sorry for the late change, but nobody wants wall collisions.
The new hash is: 29d364f8677c7c955d423747fcf5005fd00f2e6b
2 Likes
Great responsiveness thank you
Did you check this recommendation:
I’m suggesting this because of:
I don’t see any reason why I would need to increase the spread. Things will already like you have suggested because I am getting paid after the fact.
This reply is a little late but, for information, I don’t think there is a minimum offset in NuBot that would absolutely guarantee no wall collisions. There is too much variability in the price feeds that can be used. That is why the multicustodian option was developed. It was intended that this be used when multiple NuBits were being used on a single currency pair. It will force a minimum offset (just for safety) and will synchronise the NuBots so that all order movements happen each minute on the minute. That is intended to stop walls of different bots moving into each other.
@masterOfDisaster, ALPv2 uses NuBot as a client but isn’t based on it. To my mind, tolerance is a term used by the pool server to see why an order price is within a certain rank. Offset is used by the client to provide spread.
1 Like
I should have looked up the right configuration parameter.
I’m talking about this client parameter:
"wallchangeThreshold": 0.1,
Which is according to NuBot documentation:
Parameter | Default value | Description | Admitted values
wallchangeThreshold | 0.15 | how much the price needs to change to trigger a wall-shift. | double. Expressed in absolute percentage. 10 = 10% , 0.5 = 0.5%Results as of 31/05/2016:
NBT Balance: 20,429
BTC Balance: 0.0012
Simple NAV: 20,430, a 2.15% profit
Bitcoin Price Adjusted NAV: with current price of 529.38, the adjustment is -2563, so 17,866, a 10.7% loss
Bitcoin Price Adjusted With Pool Payments NAV: NuPool rewards total 578, so 18,445, a 7.78% loss. Annualised and compounded rate of loss is 55%.
The adjusted NAVs have fallen a great deal over the last week because the account has been all NuBits while Bitcoin has risen.
3 Likes