I have probably missed something, but how can you have fixed size payments to participants denominated as interest rate?
Should that not be determined by conditions on market and dependant on actual volume?
I think I don’t understand the question. The server validates request every 3 seconds. For each of these requests it credits the interest rate times the provided liquidity at this point (where the interest rate is broken down to interest per 3 seconds). So it is not fixed size in this sense, if this was what you were asking.
Low volume itself is not tackled by the system (I am also not sure how to encourage volume without doing immoral things). Unbalanced liquidity is first attacked by having a specific target value for both sides of the market, so if the buy side liquidity is full then the server will not compensate any funds above this target.
The other force to counteract unbalanced liquidity is the variable interest rate approach described above, such that user can propose a minimal interest rate they are willing to get. The market then (hopefully) will automatically rebalance since the interest rate for the underperforming side will increase.
All above thoughts rely on the assumption that there are enough pool participants in order to create this competition.
updated to the latest verion. Got error
> python ./client.py 104.245.36.10:2020 Traceback (most recent call last): File "./client.py", line 140, in <module> cost = { 'bid' : exchangeinfo[name][unit]['bid']['rate'], 'ask' : exchangeinfo[name][unit]['ask']['rate'] }
bad move 
I didn’t branch correctly and then pushed into master after a while, I’m a git noob. If you want I’ll look up the commit for you where it should still work with the old server.
EDIT: here it is: 34155c9855f4ded330c266de609c71777417df48
git checkout 34155c9855f4ded330c266de609c71777417df48
I am in the final testing phase of the new server / client system and will install it tomorrow if everything goes well. Then you will be able to connect with the new client (although I will change the port to avoid more incompatible connection attempts).
1 Like
Never mind. Take your time.
Successfully testing on Win7-64bit with Python and NuPool 0.15.
100% efficiency, 0 rejects. Seeing my ‘reward balance’ going up every minute. Neat. Already earned 0.0001 NBT after 10 minutes.
The python download and the funds transfer took me the most time 
It is really simple to install, although I can imagine that some users shy away from completing the user.dat. A simple gui would make it more user-friendly.
Looking forward to further developments.
Hello Nu community,
The one week of the initial beta phase is over. Up to 17 keys were connected at some days and the frequent server crashes might have discouraged some, but in total I am very happy with the general performance and in particular about the feedback I got. I will probably also prepare some visual data when I find to the time.
Many issues were reported and partly fixed on the fly, however, some problem required deeper changes. Today I would like to start a second beta run, which uses an improved client / server architecture and many new features.
Variable interest
This is the major feature which comes with this release and which I would like to test during the beta run. For every key in the users.dat you need to specify two additional numbers which correspond to the minimal interest rate you are willing to get for your liquidity in percent, for the buy and ask side respectively.
So each line in the users.dat now looks like this
payout-nubits-address btc exchange api-key api-secret bid-interest ask-interest
Example:
BQRKF4X8gFLyHGVeym8tuff57PcJczYPVg btc poloniex 85BQTQG1-N3D3PFKX-YUNIHIO1-WQCWTRER 1234abc 0.8 1.2
In the example I am asking for 0.8% on the buy liquidity that I am providing, and 1.2% on the sell liquidity
Please connect your client to the new server (note that I changed the port again to 2022):
./client.py 104.245.36.10:2022
During the second phase of the beta I am paying up to 5% per day for a target liquidity up to 20.0 NBT for each side of the market. The reason for the small target values is to see as much competition as possible, because the variable interest rate rule only goes into action if the liquidity provided is above the target value.
Interest calculation
This section is only for the people who are interested - you don’t have to take any action to improve the interest you get. The server will always pay you the maximal possible interest rate. My goal is to ensure these two points:
- Increasing your minimal interest will never increase your payout, decreasing it will never decrease your payout
- Increasing your funds used will never decrease your payout, decreasing it will never increase your payout
This is ensured on server side by sorting all orders by their minimal interest and then to pick the next higher interest seen in the order list for each user.
UPDATE: In order to ensure (1) a different server behavior had to be implemented. The server now calculates the total amount of coins above the target and compensates them as described above (up to the limit). The remaining liquidity is paid with the pool’s maximum interest. See the updated examples below to see how the effect of this change.
Example
Let’s consider some examples to clarify what this means. Here the server now provides 5% maximal interest up to a target limit of 20 NBT, as used in the second beta run.
Two users, Alice and Bob, are providing liquidity in our example and Alice asks for a minimal interest rate of 2% and Bob asks for a minimal interest rate of 3%. We further assume a single market side on one market (e.g. sell side on Poloniex).
-
Alice and Bob both provide 10 NBT
Payout: Both will get 5% * 10 NBT
Reason: Their combined liquidity is 20.0 NBT which is within the target. -
Alice provides 10 NBT and Bob provides 15 NBT
Payout: Alice will get 5 NBT * 3% + 5 NBT * 5% and Bob will get 5 NBT * 0% + 10 NBT * 5%
Reason: The total amount is above the target and clients are in competition for the 5 NBT which was provided in addition to the target value. Bob is not willing to provide NBT for less than 3%, but Alice is, so the system will grant these 5 NBT to Alice at the best possible interest rate for Alice (3% - epsilon = 3%). The remaining target will be filled with remaining 5 NBT of Alice first, end then finally with 10 NBT of Bob’s liquidity at the pool’s maximal interest rate.
2.1 Alice decreases her minimal interest rate to 1%
Payout: The same, since she will still get Bob’s 3%.
2.2 Bob decreases his minimal interest rate to 2.5%
Payout: Alice’s payout interest rate on her 5 NBT will reduce to 2.5%.
2.3 Alice increases her funds by 5 NBT (i.e. from 10 NBT to 15 NBT)
Payout: Alice will get 10 NBT * 3% + 5 NBT * 5%, Bob will get 5 NBT * 5%
Reason: The amount of liquidity above the target increased from 5 to 10 NBT. Alice still has the best offer, so her 10 NBT will be compensated first.
2.4 Willy joins the pool as third participant with 4% minimal interest
Payout: 10 Bob’s payout interest rate reduces to 4%, willy won’t get any payout
2.5 Joe joins the pool as third participant with 1% minimal interest and 15 NBT
Payout: Joe will get 2% * 15 NBT, Alice will get 3% * 5 NBT, Bob will get nothing
Important: Clients will remove orders which give 0% interest. So from now on you might find some funds on your exchange account which are not in orders. If you are not planning to decrease your minimal interest rate, then you should remove some of those funds from the exchange in order to reduce your risk.
I hope these examples help to understand the basic idea and I further hope that there isn’t some major flaw in the concept I do not see. So would be nice if our economy experts would give it a thought.
Oh you will like what @woolly_sammoth is currently finalizing. It will be a high class platform independent GUI which brings a lot of fun into the whole process, and of course makes it also very easy to configure.
EDIT: One more thing for the shareholders: The interest rate will be passed over to the final liquidity fee. Every minute (where the pool credits payouts), the server updates this page: http://104.245.36.10:2022/exchanges
I know its horrible to read for humans, but it allows to verify at any point in time which interest rates the server payed to the customers. In order to check if the server tricks the data, you can run a simple bot that places small orders, sends them to the server and checks the payout obtained. I am very open for discussions about the problem of proving interest rates to the shareholders - this solution is the best I got so far but I am willing to spend serious development effort to make this verifiable for the shareholders if the current method is not sufficient.
6 Likes
This is disappointing.
1 Like
Here if Alice increases her minimal interest rate to 4%, she will get in fact 10NBT * 5% which is more than 10 NBT * 3%.
That is contradictory to
or should I interpret payout as the maximal absolute reward?
EDIT: typo.
1 Like
If Alice increases her minimal interest rate to 4% then Bob’s 15 NBT will be used first, leading to 15 NBT * 4% for Bob and 5 NBT * 5 % for Alice.
Uuuugh but you are right if we change Bob’s 15 NBT to 11 NBT 
So there is a flaw, thanks for pointing it out. I think about it - if you have an idea how to fix this then I would appreciate if you let me know.
1 Like
For OSX users, you should already have Python installed as part of your base OS, so you just need to run the client from the python folder in Terminal.app using:
./client.py 104.245.36.10:2022
Following up on
I think I found my wrong thinking, If Alice provides 10 NBT and Bob 15 NBT then only the 10 + 15 - 20 = 5 NBT should be compensated with a lower interest than the pool’s maximum, and 20 - 5 = 15 NBT should be compensated with the maximal interest.
Case 1: Alice provides 10 NBT at 2%, Bob 15 NBT at 3%
-> This will give Alice 5 NBT * 5% + 5 NBT * 3% and Bob 10 NBT * 5% + 5 NBT * 0%.
Case 1.1 Now Alice increases her minimal interest rate to 4%
-> Alice will get 5 NBT * 5% + 5 NBT * 0% and Bob will get 10 NBT * 5% + 5 NBT * 4%.
Case 2: Alice provides 10 NBT at 2%, Bob 11 NBT at 3%
-> Alice gets 9 NBT * 5% + 1 NBT * 3%, Bob gets 10 NBT * 5% + 1 NBT * 0%.
Case 2.1 Alice increases her minimal interest rate to 4%
-> Alice gets 9 NBT * 5% + 1 NBT * 0%, Bob gets 10 NBT * 5% + 1 NBT * 4%
I will implement this above now, if you see any further problems, let me know 
The server is updated. It involves the new interest calculation inspired by @cryptog’s counterexample and a bug @willy found that didn’t allow users to overwrite their minimal interest rate. The latter problem unfortunately required a change in the server / client communication, which is why you need to update in order to connect to the new server.
So please update your git or download the new client from here: https://github.com/creon-nu/nu-pool/releases/tag/0.22
My apologies for the frequent updates. Even if there will be another change in the interest calculation, I hope that this won’t involve you to take any action.
Please point the new client to port 2222: ./client.py 104.245.36.10:2222
I’ll keep the old server running for a while and notified the clients that they should update. Thanks!
1 Like
Considering this is beta, I say bring on the updates!
1 Like
on it, 10 minutes
1 Like
Up again and issue fixed, will also release a small client update within the next hour which should handle tier 2 <-> tier 1 movements better. Thanks for your patience.
1 Like
up and running.
by the way I forgot what is the rate displayed in the stats output by clients.py …
I asked for 1% of minimal rate on each side in users.dat but the command line outputs sometimes 0.37%, sometimes 0% sometimes 1.66% …
The rate is the effective interest rate, which is the payout you got divided by the total amount of NBT in your orders. If someone offers liquidity for a better interest rate (and the pool is above the target which currently almost always is the case), then the pool will compensate fewer of your orders and your effective interest rate will go down. Your client then should remove these funds from the order book (tier 1 -> tier 2) which will lead to an increased effective interest rate again.
Currently there are still some teething problems of the client behavior, but with the coming client update I hope that we are pretty close to the scenario described above.
1 Like
OK here we go: https://github.com/creon-nu/nu-pool/releases/tag/0.23
This client update greatly increases the client’s performance in setting the optimal amount of funds into tier 1 liquidity and also fixes some bugs in the client behavior. Its still not perfect yet but works quite well. The update is not mandatory though, but recommended.
A lot of competition is building up on some exchanges. Remember that, assuming the modified system works correctly, you can really specify the minimal interest you are willing to get - the server will always pay the maximal interest possible for you. There is no need to tune this parameter.
Enjoy!
2 Likes