[Passed] NuPool 5

[Nagalim]

what parameters NuPool would be best

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.

[woolly_sammoth]

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.

[masterOfDisaster]

You definitely have a greater understanding of the intricacies of spread, tolerance, deviation and offset than a lot of other shareholders, myself included

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.

I know LP’s aren’t complaining now, but shareholders are complaining about the rates.

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…

[cryptog]

a lot of them don’t understand enough of the mathematical basics of liquidity providing.

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.

[Nagalim]

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.

[crypto_coiner]

I expect at some point in the future we will use a variant of the mini-blockchain employed by Cryptonite.

Cryptonite is interesting - but that should be decided upon motion, imho

[masterOfDisaster]

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…

[crypto_coiner]

Right - thanks for reminding me that point. I guess I’m too used to seeing Software updates without seeing their particular source of funding.

Even if it was paid by available funds, a motion would be appropriate…

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?

[masterOfDisaster]

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

• discuss it
• create a motion/grant
• wait until it passes
• raise or dedicate funds according to motion/grant
• implement the change
• test it
• let the minters switch to the new protocol

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.

[crypto_coiner]

That makes a lot of sense - great explanation.

[masterOfDisaster]

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?

[crypto_coiner]

While it is possible to calculate an exact historical average for the amount of space taken up by a custodial grant vote, I would bet it is between 150 and 300 kilobytes. I expect at some point in the future we will use a variant of the mini-blockchain employed by Cryptonite. This will mean the typical shareholder will not hold old custodial grant votes on their blockchain.

But yeah, I don’t mind the move

[masterOfDisaster]

Ah, oh, yeah. Got it. @JordanLee started to derail the thread!

[crypto_coiner]

voted for that grant

[willy]

50.29% in the last 5000 blocks, but SDD lagging behind with 38.55%.

I can’t remember seeing the votes deviate from the SDD so much… mh.

[Nagalim]

This has passed.

[CoinGame]

[Nagalim]

Good parameters for LPs on these pools are:

Deviation = 0.0025
Offset = 0.0045
Resultant Spread After Fees (SAF) on Poloniex = 0.5%
Resultant SAF on Bittrex = 0.4%

[leka]

* The SouthXChange wrapper is currently being developed by @TheCrema and is getting tested as we speak

Any update regarding this?

[willy]

@thecrema is close to finishing the wrapper. We are not far away.