[NuPool] Announcing: Trustless liquidity pool operation “NuPool” on Bittrex.com has started

It looks like the client is checking the orders periodically and adding an amount to my balance, if this is 0.25% per check, where do you get the 0.25% per day value from? i.e. 0.25% of what per day?

Also, is the balance in NBT or BTC?

Yes, per day. However, you are getting liquidity credited every minute. How much depends on the orders you have set and if their proof arrives at the server and the exchange. The liquidity amount seen by the server over the last minute is shown in the output of your client.

So the interest rate shows a “per day” value as you correctly say, but internally its broken down to a per minute payout. The balance is NBT.

Does this mean that ‘per day’ doesn’t really mean anything?

Is there a way to calculate what the payout would be for a given day considering that the amount in the order is a dynamic value that is unpredictable?

No, if your liquidity changes a lot it is hard to guess how much you get per day. But usually your liquidity is pretty constant and if you have 100% efficiency as most clients then you can take this number as very robust estimate for your daily payout.

It only becomes unpredictable if you either have a bad connection to the server, or if you are in competition with other pool participants because the target was reached. But you will never get less than your minimal interest rate set, even if this means that your bot has to remove some of your funds from the order book.

So do I multiply interest rate times liquidity and multiply by 1440? (minutes per day)

No you sum up the liquidity shown in your client each minute and multiply it be the interest over one day and divide this value by 1440 and you will have your payout. The interest rate shown there is a “per day” value. You can also just divide the interest rate you see by 1440 and consider at every minute. This is the value shown after “ppm” (payout per minute).


0 buy side liquidity currently: {“credits”: 37628, “users”: 11, “validations”: 451543, “liquidity”: [0.0, 7938.904999999996], “sampling”: 12}

why is the pybot of bittrex not picking up any bid orders? Has been 0 for a while now…
ask orders are fine though…

HI @PinkyAndTheBrain. Thanks for the heads up. I’m investigating now. I know there is a bug which causes the bot to not place all balance on order when certain conditions are met. I think the changing BTC price may be causing those conditions to be met more often.
Restarting the bot normally fixes the issue but is far from ideal. I’m hoping that the coming NuBot release will cure a lot of the issues we are seeing with the current implementation

Edit: There was a low hanging ask order that was preventing bid orders from being placed. I’ve cleared that now and (hopefully) the client should act normally now.

Yah, I implemented an automatic restart on the tllp client because of stuff like this. The bugs in our tllp system are a little embarrassing, but I’m also hopeful that fixing issues farther down the line will cure some of these bugs.


I agree. The issue is that the bugs are all in the portion of code that is most complicated and lacks explanation. The NuBot update does address a lot of the issues but will, I’m sure, add a few issues of it’s own. I’m concentrating on that release as a priority now.


How do you restart the tllp client automatically without just killing the process (which doesn’t delete the orders as it’s no clean shutdown)?
All my bots (I have one at liquidbits, nupondCNY and nupool :wink: ) are running remarkably stable at the moment, but I’d like to know anyway.

1 Like

At the moment that’s it I’m afraid. If you are running on just a single exchange and running the TLLP client in the traditional way it should shutdown cleanly and cancel the orders. The issue arises if you run the client in the background with `nohup`` and the like, or using the run_client script for multiple exchanges. Then the shutdown is forced and the orders aren;t cancelled.
I’ll add this need to the todo list for the next release.

So at the moment something like this is the best you can do?

#!/bin/bash echo "starting nupool in the background" function background_loop while :; do pkill -f client.py ~/apps/nupool/unix/client >/dev/null 2>&1 sleep 600 done background_loop &

I would very much welcome you putting other ways of shutting down a tllp client to your todo list :wink:
…this would provide an even better liquidity, because tllp bots wouldn’t go nuts and kepp the funds off the order book…


my usual tactic is to get the main loop of an application to check the existence of a file in the file system (usually just called ‘run’). The application creates that file on startup and then stops if it is missing for any reason. You can then just remove that file to stop the application even if it’s running in the background.
I’ll definitely bump this up the todo list as it should be fairly easy to accomplish.

fyi, i can restart all iwant, it remains at 0% https://raw.nupool.net/?pairs=true

I have played with two ways of running a tllp bot

  • running it within a screen session and connect to it from time to time to check the status - being able to shut it doewn properly if need be
  • running it in the background with periodic restarts - no real interaction and no way to check the status without looking at the exchange

My conclusion is:
even if the tllp bot sometimes goes nuts and needs to be restarted this is the lesser evil. I faced legions of stranded 1 NBT orders that remained after killing the tllp bot (instead of shutting it doen properly). As they weren’t removed after the tllp bot started again they piled up until I noticed that.
Deleting them was something I don’t want to do again soon :wink: I rather have a tllp bot that doesn’t provide liquidity for some hours or a few days.
A config parameter to recycle the tllp bot after a given time would be great!

But before I sidetrack the topic, I give you the feedback that the last run of my nupool tllp bot was from
2015/06/28-11:19:44 to
and only ended because of a power outage at my RaspberryPi.

I added this to tading.py:

totime = time.time() - self.startime
if totime > (self.restime*3600):
python = sys.executable
os.execl(python, python, * sys.argv)
print “issues restarting bot”

I’ve been using this for a while, I made it a config parameter, and it works alright for a workaround. https://github.com/Nagalim/nu-pool

Does it place the orders and just not validate them? I have been suspicious of nupool’s 0.0085 tolerance since I had trouble getting my bot to work on poloniex. I’m wondering if the nupool price feed is off for some reason, so it validates orders that are higher than the price but fails at validating lower than the price.

@masterOfDisater - that’s some run! a config parameter to recycle the client is a good idea and one that I’ll look into.

@PinkyAndTheBrain - there are still ask orders on Bittrex that are lower than the tllp calculated bid price. That is causing the client to not pace orders as they are being run with ordermatch = False.
I don;t have enough funds to clear the ~22BTC worth of orders that are causing the block. Similar things did happen in the early days of NuPool and we found that they do tend to clear as the BTC price moves. If anyone wants to help out, you can run your client with ordermatch = True in your config. This will force the bid order to be placed and filled immediately with the low priced NuBits. It means you get NuBits for a lower price than that calculated by NuPool which may be what you want but may not be. I have set this as the default behaviour in the next release.

There have not been any changes to the price feed code on NuPool and the settings are exactly as they have been for the last 2 operations.