Good evening everyone.
Just a short update. The rolled over pool funds from the 4th operation ran out and we were at risk of not being able to pay pool compensation. Instead of turning the pool off until this proposal passes, @willy has added personal funds to the pool to ensure continued operation (thank you willy).
Having looked at the situation with the unbalanced volumes on the supported exchanges, I can see that it is something that needs attention. I was perhaps a little rash in starting the the 5th operation of NuPool before garnering full opinion from shareholders but, as this proposal is being actively voted on, I am loathe to change the parameters presented in it.
I was happy to see that @henry has stepped in to help by supporting Poloniex with the NuLagoon and do think that NuPool should assist if it can.
The only way I can think to do that, while leaving this proposal intact, is to submit a second grant proposal to fund an increase in target at Poloniex. An increase of the target at Poloniex to 35,000 at the current rate would cost 900 NBT. Do shareholders think that this is a valid use of funds at this time or is the feeling that the support of the NuLagoon is enough to last the next 27 days and to re-examine the targets on NuPool then.
Again, apologies for jumping the gun and starting this operation prematurely (although actually late). As stated in the OP, I will do my best to be more focused from now on.
Why don’t you propose a motion to lower bittrex to 15,000 and increase polo to 35,000?
I think it is worth experimenting an increase of the incentive to provide liquidity to Polo.
In the worst case, the Nu decentralized corporation would lose 900 NBT which is not catastrophic.
Therefore, I would be in favor of an additional grant.
I would like to monitor this for some time. The new targets are ~60-70% filled on poloniex, which doesn’t really trigger a need for immediate action in me.
Would NuPool operators ever consider complying with [Passed] Motion to regulate spread values for liquidity operations? The NuPool operation on Poloniex is without a doubt our highest volume ALP operation. If NuPool operators refuse to comply with this motion, we should amend the motion. Otherwise, it simply looks like the shareholders have no teeth (which, honestly, we don’t regarding NuPool because we need its service; however there’s no need to flaunt it publicly.)
Can you elaborate on which part of the motion you mean exactly?
With a 0.2% fee, a 0.85% tolerance would require a 0.1% deviation. Do you expect LP’s to be using a 0.1% deviation? If so, why is the default 0.25%? Have you tried running the bot at 0.1% deviation? I think you’ll find it replaces orders much more often than you would like.
A 1% tolerance would give the 1% spread after fees that the motion implies and still allow LP’s to use a deviation of ~0.24%.
The settings we are using on for NuPool have remained constant since the very first operation. It is expected that most users of the pool are using the client software with the default settings. We’ve not had any complaints and the software is working as expected.
We haven’t been deliberately ignoring any motion raised for the pools. We’ve been operating under what is easiest. As stated a few times in this post, time has been hard to come by in the last few months. There are things that I would like to have happened with NuPool, and with providing assistance to the other pools that just haven’t happened and I am sorry for that.
You definitely have a greater understanding of the intricacies of spread, tolerance, deviation and offset than a lot of other shareholders, myself included. Would it be OK if I picked your brains around what parameters NuPool would be best to target in the next operation?
I still hope that the pools will be using NuBot in the future instead of PyBot but, as with the other issues, that has taken longer to implement that I had hoped.
I cannot answer this, but I can say what my I terpretation of that motion was. It was defining what we accept as our standard for how much we want LP’s to get as income from the volume. That definition says that the actual default ‘offset’ parameter in our pool software branches use the motion specified ‘0.5% + fees’.
To accomplish this, we need to give the bots room for their wide spread in addition to the room required for the basic function of using a price feed. I think the deviation should be between 0.2% and 0.3%, but I am not nearly confident enough to cement that in motion. In addition, I imagine the possibility for the server price to differ from the client price. Therefore:
To achieve Spread-After-Fees = 1%
We want Offset = 0.7%
With Deviation = 0.25%
Use Tolerance = 1%
LP’s can totally tighten up the parameters for additional spread, but most won’t and getting your order filled is actually a boon with high spread, not a curse. Additionally, it becomes obvious if someone is using a drastically wider spread and the default parameters can be refined with time if LP’s complain.
I know LP’s aren’t complaining now, but shareholders are complaining about the rates.
I hear what you’re saying and agree that it is unlikely to be the LPs who complain if the pool is operating with unnecessarily beneficial parameters.
I think I need to have a good re-read of the motion you linked to and carry on the conversation you’ve started with all the pool operators, and wider shareholders, to see what is the best course of action.
With the operation of NuPool, we had planned to use this operation to try some different things to previous NuPool runs. Unfortunately time ran away and we thought it best to just continue for another 30 days and use that time to assess what changes to make.
The things we had discussed were: Extending the operational period to 60 days, Expanding to operate on different exchanges (southXchange was the one in mind), Setting different targets and different rates.
Given the comments in this thread I think that we should definitely look at making some calculated changes to the operations of NuPool to take them and the other changes on board.
I think @woolly_sammoth has given the reason for the share holders not complaining more - a lot of them don’t understand enough of the mathematical basics of liquidity providing. So it might “feel” for them like something isn’t right, but pnly few can name what’s wrong.
Thank you, @nagalim, for hearing the complaints and trying to bring the interests of LPs and NSR holders on a measurable and fair level.
That’s very far-sighted! Risking trouble between Nu and the LPs could lead to dangerous situations…
I confirm. I tried several times to wrap my mind around the parameters but did not get to grasp the concrete meaning. Therefore I cannot take decisions about whether certain parameters are too expensive for a certain risk and potential reward.
That was the point of that motion: to avoid talking about complicated parameters and get at what shareholders actually care about: the spread after fees. If we choose a particular spread after fees, which is a very quantitative and understandable quantity, the rest of the parameters are chosen for us.
The pool operators, at least, should know what ‘tolerance’ is and should be proposong both a tolerance and a proposed default spread-after-fees that corresponds to that tolerance in every grant proposal. Currently, pool operators are proposing the tolerance, which is great for anyone who knows the math, but they should give the spread-after-fees too (or equivalently the offset) because it’s vastly simpler for shareholders to understand.
Cryptonite is interesting - but that should be decided upon motion, imho
Sure, it needs to be done this way or how do you expect the funds for the development to be raised if not by NSR or NBT grant?
Even if it was paid by available funds, a motion would be appropriate…
Right - thanks for reminding me that point. I guess I’m too used to seeing Software updates without seeing their particular source of funding.
To which extent an integration of a feature such as cryptonite could be conducted without any motion, in the case it was paid by available funds?
I think this depends on whom you ask
My understanding is that the proper way to do an implementation like this, is
As you can see the NSR holders (who mint) can ultimately determine whether the Nu network switches to that fork.
It would be wise - and so far I have seen a lot of wise behaviour in the Nu network - to include NSR holders right from the start.
As this type of change provides incredible scalability benefit it’s worthwhile to start a discussion about that
before it starts to be necessary.
NSR holders can be glad that the Nu network is still in its infancy (giving room for changes like this) - although I think some very important steps have already been made.
That makes a lot of sense - great explanation.
How did the cryptonite idea finds its way into this topic? I think the last posts should be moved to the appropriate thread, don’t you think @crypto_coiner?