Trust-less liquidity pool

The reason for this is simply that the legal framework in my home country would make it difficult and very expensive to allow me to run such an operation. This would also be true for a bitcoin mining pool for example. @woolly_sammoth is a person where I feel very comfortable to let him run the operation and he doesn’t have these problems. The software is just the same and I will be part of the team.

Note however that neither @woolly_sammoth nor me will be responsible for any damage that will occur. The only part of the software which actually could lead to a loss if it contains a bug is the trading bot. If you look at the NuBot for example, then you will see that it contains a similar disclaimer and you cannot demand anything from the developers when it didn’t do what you wanted. This is common practice in open source projects.

Also note that you are free to disable the trading bot and to place the orders manually or to use any other trading bot implementation you like. If you do that then it is impossible that my software will make you lose money at any time.

EDIT: I should mention that the risk for the shareholders is by design small. Shareholders pay for the amount of liquidity provided, not more and not less. If the pool fails after 3 days and does not provide liquidity anymore, then the remaining NBT of the grant will be burned.

1 Like

Wo. I was assuming that you would not need a legal framework but if we want to build a network of Nu liquidity provision operators around the world as Humanity has with regards to bitcoin and its mining, it seems that having a legal status is the right direction to go.

Could you let me know how I can do that? I am not saying that I would want to use something different than PyBot or NuBot but I am just curious.

Generally speaking, that would be great to have some sort of documentation attached to nu-pool code source so that anybody that can run a python script can contribute to the liquidity provision easily.

Run the client with none instead of pybot or nubot in the users.dat and it will just not run a trading bot, but only send order requests.

Without any bot you could open http://104.245.36.10:3333/price/btc in a browser, check the btc price, and then go on the exchange and place an order at this price ± 0.5%. Your client then should provide exactly the same output as if the bot would have placed the order … as long as the price is in the correct range.

Absolutely, I neglected this quite a bit during development. This will be improved.

2 Likes

Tks a lot for the details.

By the way, I have not understood yet how the algorithm behaves if I specify no minimal rate…(which is what I am doing right now.)
Would it set my fund always first compared to the other funds?

Furthermore, I suppose that if 2 contributors come up with the same minimal rate, the one that would see its fund put into orders first is the one with the earliest timestamp. Correct?

Just a data point - I haven’t been able to connect to or have the client.py script to work (it just produces no output) for about 10 days for unknown reason. I have tried to run from ISP in China, the US, and France. It is possible a problem from my laptop. But the laptop has had no other internet acccess pproblems.

If you remember that ugly post where I introduced the most recent system you remember that there were always two important interest rate levels which are determined based on the liquidity provided and which interest rates were given by the user. From these two interest rate levels, one is larger (high) and one is smaller (low).

Liquidity up to the target will compensated, partly at the high interest rate and partly at the low. Every participant whos interest rate is smaller than high will be compensated according to his or her contribution. Every participant with an interest rate < low will additionally compensated at the lower interest rate according to the contribution.

EDIT: To answer your question more directly: If you provide no interest rates at all, then it takes the pool’s maximum which will then be compensated according to the rule above.

This all is not the case anymore. If the target is 50 and both contributors provide 30 at the exact same interest rate, then each of them will get 30/(30+30) x 50 = 25 NBT compensated.

Very interesting. The current server is located in San Francisco, California. Are you able to access the json API via browser? e.g. http://104.245.36.10:3333/status

Otherwise I would appreciate if you could send me your log file. It does not contain your api secret, ideally check for it of course. The client doesn’t print those messages to the terminal anymore for some releases.

EDIT: @mhps, if you can not access the json API link above, can you try to access just http://104.245.36.10/ ? It should show some Apache2 Ubuntu default page. If you can see this, but not the json API link, then this might be a port issue. The final operation will probably run on port 80, such that this problem would be avoided.

Hi,

a small update:

  • server: reimplementation of credit system
  • client: payout per minute in output-
  • bitcoincoid: nonce search improved
  • many additional small tweaks

I recommend clients to upgrade to the newest version:

https://github.com/creon-nu/nu-pool/releases/tag/0.5

The next step will be integrating Bittrex compatibility. Their API allows for some interesting features which theoretically would allow users to get paid without even being connected to the server.

3 Likes

You must be talking about: Trust-less liquidity pool

So putting no min interest makes you the latest one to be served?
Let us say that the pool offers sell liquidity up to 100NBT at 5% daily interest

A) offers 50NBT at 3% min
B) offers 25NBT at 2% min
C) offers 25NBT at 1% min
D) offers 50NBT with not min.

In that setting, C) will get 2% on 25NBT, B) will get 3% on 25NBT, A) will get 5% on 50NBT and D) will get 0% on 50NBT or is it the other way around, that is to say D) will get 1% on 50NBT ?

In total there are 150 NBT with a target of 100 NBT, so 50 of these 100 NBT will be compensated at 5% and 50 will be compensated at 3%. The higher payout level will be served first. Since everyone’s min interest rate is below 5%, also everyone is in the higher payout level, and each one will get:

5% * 50 * x / (50+25+25+50) where x is the offering. So nobody will be served “first”, they all get served at the same time according to their contribution.

The second payout level is 3%. B and C have a intrest rate which is strictly smaller than 3%. Therefore the remaining 50 NBT will be compensated to them at 3%:

3% * 50 * x / (25+25)

So there is no ordering of the users beyond the minimal interest rate ranking. You are getting paid for the fraction of the total liquidity that you are providing.

Getting this kind of error:

2015/04/07-10:07:48 ERROR: submit: user not found: xxx

2015/04/07-10:08:35 ERROR: unable to receive statistics for user xxx: server response invalid

Sell order successfully placed though.

CTRL + C does not suspend the process any more.

Hmm not really sure. I did a server restart a couple of hours ago, which would explain the first error and which is actually no problem (it will just register again) but all my clients continued operating fine after the restart.

Can you look into the end of the log file if there are some debug outputs?

Getting plenty of “.
2015/04/07-10:23:50 DEBUG: /register: socket error (timed out), retrying in 5 seconds with timeout 30…”

I am placing orders 3 orders on 3 different exchanges by the way (ccedk, bter, poloniex).
Worked fine yesterday.

Thanks! I think I found your bug, it didn’t stop trying to register in this case. If you are using the github then you can just update and it should be fine. I will make a new release tomorrow.

It should not happen if you don’t lose the server connection for too long.

wo that was quick! that is working with no issues now. tks.

So when there is oversupply, the program divides up the target liquidity in half and applies the target rate (the higher rate) to one half, and the highest minimum rate (the lower rate) proposed by the providers to the other half.
Also, mentioning no minimum rate prevents you from being rewarded potentially at the lower rate.

Is my interpretation correct?

I would love to see plenty of examples inside the documentation :smile:
I am sure plenty of providers would want to see concrete situations as well before setting the min rates.

Yes but your payout will always always be smaller. You can only increase your payout per minute by decreasing you interest rate (or increasing your funds). All payouts at a potentially lower interest rate are added to the payouts of the higher interest rate. Likewise, decreasing your interest rate will not remove you from the higher payout level, your contribution is still the same.

So set it to the minimum you are willing to get! It will never make your payout smaller.

1 Like

Sorry to respond so slowly. Now I can access the server alright. But I always get this error [date time] ERROR: no valid users could be found . The same line is the only line in the log file. I have tried both polonies and ccedk, and updated api keys. The users.dat has Bxxxx btc ex xxxx xxxx 0 0
where ex = poloniex or ccedk

try 0.0001 0.0001 please