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

[mhps]

Don’t you think if the interest policy is “7.5%/mo” or “1500 NBT proportional to coin-hour contributions”, which ever is greater, then there would be more incentive to participate, because if there are a few participants, they will set to split the whole reward? This needs to get pre-approved by the shareholders tho.

If you have a daily notice showing what reward rate would be if participation keeps at current level until term-end, then people can evaluate risk-reward often.

Generally I think shareholders should consider encouraging liquidity provision when everyone wants to pull the fund. It has two aspects:

1. encourage liquidity provision when liquidity is low. This is partly taken care of by the fixed total reward above.

2. encourage liquidity provision on the less liquid side (i.e. incentivise buy/sell balancing).

[creon]

Its not necessarily “1500 NBT proportional to coin-hour contributions”. The variable interest rate system ensures both points you bring up.

You can, and should, specify the minimal interest rate you are willing to get in the pool.conf. Every NBT which is above the target (10,000 NBT currently) will be compensated at lower interest rates as specified by the users. However, you will never get a larger payout by increasing your own minimal interest rate. Its based on the dutch multiple-item auction model and I formally described it here:

Trust-less liquidity pool

After studying those multiple-item dutch auction I think it is indeed exactly my model here. It is the same system eBay uses when you are not selling 1 copy of an item but 100 at once - and eBay ensures the rules I would like to see satisfied (i.e. you will never pay more on eBay just because you set a higher maximum bid initially). Here the pool is selling space (consisting of many 10^-8 NBT units) within the target for a price which is given by the interest rate. In general you can say if yo…

So if one side is overloaded, then people will get less interest on this side and there is an incentive to shift funds to the other side of the market where the interest rate is larger.

[mhps]

You can, and should, specify the minimal interest rate you are willing to get in the pool.conf.

The problem with the max rate is that it can be too low to encourage fund providers. For example when the price of BTC is plummeting, people pull their fund. Argueablly this is the time the wall is needed. If for example if there is only one person proving 100 NBT, then if everyone knows this person will collect all 1500 NBT reward in the end for 3000 coin-days, then many people might want to jump in because the reward is 1500%/mo.

So if one side is overloaded, then people will get less interest on this side and there is an incentive to shift funds to the other side of the market where the interest rate is larger.

Yes this takes care of it.

[creon]

Wait, we are not getting 1,500 NBT from the shareholders! This is the theoretical upper limit which would have only be reached if from the first moment on 20,000 NBT would have been provided at 0.25%. Since this not the case the remaining NBT will be “given back” to the shareholders, where giving back according to the grant either means that we use it for future operations or that we will burn the remaining NBT. The actual cost for the shareholders is therefore determined after the operation.

However, I like the general idea of giving a larger incentive to balance early on. One possible model would be to scale the pool’s maximum interest rate according to the current liquidity - this could be done in addition to the variable interest rate system specified by the user.

[cryptog]

The problem with the max rate is that it can be too low to encourage fund providers. For example when the price of BTC is plummeting, people pull their fund.

I agree on that. Yesterday this is what I did since I lost 5% over 24h. The 0.25% was not enough to counterbalance the cost.

One possible model would be to scale the pool’s maximum interest rate according to the current liquidity

That would give indeed some incentive to keep the bot running in a downtrend market for example.

[Mark]

@creon, is it possible to implement BTC hedging with slightly modified version of @Hyena idea:

When Bitcoin crashes

Yes I have indeed missed the fun. Anyway, I don't like the idea of using some coinapult kind of service. Here's what I propose: Custodian will open a NBT/BTC online shop. The custodian will never hold BTC. Instead, they will hold USD in Bitstamp, for example. Because the custodian has to be a trusted entity in the first place, we would have no problem trusting them to run their independent NBT/BTC online shop. Selling nubits: 1. Customer comes to custodian's online shop 2. Customer wishes to…

Options to configure on client side:

btchedging:true/false, default:false
btcsell_limitorder:true/false, default:false (market order)
btcbuy_limitorder:true/false, default:false (market order)

===

Example, if you choose this options:

btchedging:true
btcsell_limitorder:false
btcbuy_limitorder:false

The custodian must open an account in exchange with a high liquidity, like Bitstamp for example.
The custodian should duplicate his TLLP served funds on his own Bitstamp account.

Custodian Buys NBT/Sells BTC:

1. Custodian’s buying 1000 NBT order on TLLP is fulfilled
2. Custodian’s client immediately buys 1000 USD worth of BTC on Bitstamp (market order),
   or buys on best price (If custodian has accounts on several different exchanges)

Custodian Sells NBT/Buys BTC:

1. Custodian’s buying 10 BTC order on TLLP is fulfilled
2. Custodian’s client immediately sells 10 BTC for X USD on Bitstamp (market order)
   or sells on best price (If custodian has accounts on several different exchanges)

Sorry for my English

[creon]

Yes this is a very interesting concept. @GreatScott proposed something similar somewhere. It would require some implementation effort but in general this would be possible.

However, I really don’t want this project to converge to a real trading bot in the sense that in realizes a profit optimizing strategy by performing market actions. I think the TLLP should focus on the liquidity itself.

But an independent standalone program, which essentially checks your orders on the exchange and mirrors the actions as your describe it would be a very nice project.

[mhps]

Wait, we are not getting 1,500 NBT from the shareholders!

I was suggesting possibilities for future operations.

[woolly_sammoth]

There appears to be one pool user who is using an older version of the client.
They are providing ~3900 NBT on the buy side but the server is reporting the following error
unable to validate request: too many requests received: 467

The new way the client works will reduce the number of requests that are sent and ensure that this user gets the proper compensation for their liquidity provision. The liquidity is only being reported by the pool sporadically too. With the current buy side liquidity of Nu looking so low, it would be nice to have a more stable report of the value being returned by the pool.

I would encourage everyone to ensure that they are running the lastest version of the client so that everyone gets the compensation to which they are entitled.
The lastest version of the client can be found here: https://github.com/creon-nu/nu-pool/releases/latest

[nuBie]

Hello Nu!
The whole Nu and the ways to provide liquidity (being an important aspect when trying to provide a stable crypto currency…) are intriguing me.

I’d like to try @creon’s nupool, but have stumbled upon a question for which I couldn’t find an answer.
I have decided not to use the helpdesk, because the question might be of general interest and could be included in the FAQ.

Is it possible to run nupool client with the same pool.conf on different machines?
Does this generate conflicts or is this a feasible way to create a kind of redundant client?

[creon]

Is it possible to run nupool client with the same pool.conf on different machines?

This is perfectly possible. You can run as many clients on the same key as you want. Of course you will only get rewarded once.

However, make sure to disable the trading bot on all but one of the running clients. This can be achieved by setting

trading=none

in the pool.conf. This is not crucial, but if you don’t do this then the trading bots of your clients will steal the funds of each other and will complain a lot that something is wrong which might lead to many order replacements.

EDIT: I just noticed that this parameter wasn’t documented at all. Sorry for that. I’ll update the corresponding post.

[creon]

We just hit our target of 10,000 NBT on the sell side for the first time! This means people with a minimal interest rate of 0.25% will partially not get compensated for their funds and people with lower interest rates will have priority. If you see your bot removing funds from the order book without replacing them, then either consider decreasing your minimal interest rate or remove them from the exchange to reduce your risk.

The buy side also recovered a bit and is stable around 4,500 NBT. The support is really amazing. Please report any issues you might have with your client, be it usability or efficiency problems. We want every client to work.

EDIT: Our server wasn’t so excited about that as we were and decided to kill itself. But I found the problem and fixed it. Sorry for that. All payouts have been sent. Let me know if someone is missing any balance.

[creon]

OK the 13th user that joined apparently had some interest rate set the system wasn’t able to deal with correctly. This could and should have been tested in the beta, but it never showed up in my experiments.

The issue is fixed, the server is up and running and of course I will send the payouts of the last hours soon. Sorry for the inconvenience and thank you that you all kept the client running

Also for the future: Be assured that nothing will happen to your funds. Your bot will remove them if the server is down for more than 2 minutes, so don’t worry about that.

EDIT: You may have noticed a couple more server restarts. I thought it may be wise to use this irregular downtime to push some other server updates I was planning to do. However, you should also always have been compensated with at least the amount you had as balance. I also made a new client version:

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

If you experiencing a problem that your client does place not more than 0.5 NBT then updating to this version should help. It also contains a message feature that allows me as server operator to post you a message in the client in order to inform you about a mandatory update, if there is any.

[creon]

Today is a good day. We are currently submitting 12,900 NBT on the buy side and 6250 NBT on the sell side.

Of course shareholders will only compensate 10,000 NBT of the buy side liquidity so we currently get 2,900 NBT buy side liquidity for free.

[GLock]

Great stuff! Is there a way to check the current liquidity on buy and sell side?

[creon]

Here is our server data: http://eu.nupool.net/status

The first number in the liquidity list is buy side, the second number is sell side.

You can also go into your client, Help -> Debug Window -> Console and then type getliquidityinfo B and look for the address BNUpooLxGbHXSs7Qcwi5EBXzZ82BbWwsMN.

[cryptog]

Impressive!

[creon]

OK we are officially full now and clients start to decrease their funds on both sides. Anyone who wants something from the cake needs to provide liquidity for less than 0.25% per day on both sides.

20,000 NBT on a new exchange within 2 weeks and without any particular PR effort and using a completely new and unknown software users have to run. The concept works, attracts users, and shifts the competition from LPCs to independent liquidity providers.

This is an open call to anyone who feels capable to run such a server, we need many different independent LPCs, not two or three big pools. Here is a working option which allows you to be an LPC without being rich. Anyone who is interested, please PM me, I am not asking for any compensation.

[mhps]

Terrific. Can the server supporting this level of number of clients run on a raspberry pi?

[creon]

Good question. My client runs on a raspi 1 without any problem. To run a server with 16 users I could imagine that its a bit weak iconsidering that you also need a Nu daemon in parallel.

A raspi 2 has more performance than our current server and will easily handle this amount of users.