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:
encourage liquidity provision when liquidity is low. This is partly taken care of by the fixed total reward above.
encourage liquidity provision on the less liquid side (i.e. incentivise buy/sell balancing).
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:
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.
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.
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.
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.
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
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?
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
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.
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.
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:
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.
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.