[Passed] Motion to regulate spread values for liquidity operations

Made some minor edits and up for voting.

1 Like

I support this motion

1 Like

voted

0ec0be7f113a0bf6ff603545a974cd6410458e00 verified and voted.

By the way, can you detail about “lower limit” is below?

That wording is not in the motion, is it? I couldn’t find it.

The lower limit as the wording suggests is allowed to differ by exchange (because it is a function of the exchange fee and currency pair), and the lower and upper limits limits for each trading pair is given above this part in the motion text. Can you tell me what forbids you from arriving at my intended interpretation?

Looking at the vote movement it seems the proportion of votes might stagnate below 40%. As this motion is a small part of the bigger picture of shaping liquidity provision standards I urge shareholders to give it some more consideration.

The motion might not be very good as-is but I believe sooner or later we have to move in this direction of deciding what people (shareholders, liquidity providers, users) should expect from NBT liquidity. If we can’t discuss and come to agreement on something as simple as this, it would be even more difficult when we have to adapt to more sophisticated requirements; getting NuBot out isn’t going to make this point irrelevant.

If you do not support this motion for some reason, please let us know why and we can see how to patch things up. Thanks.

1 Like

Extract of motion:

In response of:

I do not like a mandatory offset on top of the exchange fee on the NBT/fiat pairs. I still think that this doesn’t need to be specified and I think Nu is too you to allow large spreads. I think we need to encourage trading, not discourage at this stage. Happy to pay the price for that right now.

Therefore I think the motion is confusing and steering toward an undesirable direction or standard at this stage. The offset can just be zero.

2 Likes

If the offset is zero the bots will trade with themselves and we will burn all liquidity instantly in exchange fees. I think you mean to say that the offset must be some finite number, most likely the exchange fees.

What you aren’t realizing is that I’ve been running the only pool with a maximum offset less than %0.5. I can run my tllp bot on all your pools with a %0.5 offset. The biggest thing this motion is saying is that we should encourage our users to fairly explore the parameter space. This motion also gives guidelines for what that parameter space is.

You think you’re running a %0.2 offset pool because your providers are not savvy enough to change the parameters in their own trading.py files. But one day they will, and you’ll notice that your walls are not at a tight spread anymore. If you don’t like the numbers in this proposal, state some numbers you think are more fair. However, no one has really tested a %0.2 offset server side but me, the tight spread we have on pools now is just because of the tech ignorance of our providers.

1 Like

Yes, that is what I believe I said.

I’ve tested a 0.2% offset for the exchange fees since the start. And practically that has been in place all the time as far as I’ve noticed. I have not been aware that it is possible for the LPC to change that single-handedly and if true I will try to have that changed and make it either impossible or reduce the interest rate.

The pool operator has a contract with the Shareholders to provide liquidity with a certain offset to cover exchange fees and is paid for that. When LPCs are able to increase the spreads the risk decreases for them and the pool operator should be able to reduce the fees as higher spreads are less attractive for the Shareholders.

TL’DR Offset should be zero (after exchange rates). Higher offsets will be compensated less by Shareholders. In my opinion that should be the standard and every pool operator should take that into account.

What tolerance does that correspond to? There are at least practical minimums for these things. If you look between exchanges, you will have a hard time actually coming up with a picture of the price of btc within %0.4 (your ideal total spread). What does that mean for the hyper low fees of exchanges like CCEDK?

I was never told what tolerance to run. I run 0.0085 on my btc pool, because that’s what Creon ran. This motion is the only motion that actually specified a contract to me about what offset to have. Again, every single tllp except my cny pool allows a %0.5 offset, so either we’re all breaking contract or that particular contract doesn’t exist.

Change the ‘spread’ variable on line 207 of trading.py in your master directory from github to read ‘0.004’ and it will still run perfectly well on all your pools.

Here and there I see some detailed issues but ultimately the culprit is a fundamental disagreement on whether we want larger spread values. Fine, I will redo another draft to reduce the scope of the motion, so at least there’s something put forward. Next time I will try to reduce the motion to some bare minimums like disclosure of offsets and default settings. Hopefully shareholders can agree on this.

At this point I just hope objections could be raised earlier and more explicitly, and people could at least try to get a lesson out of the discussion. Perhaps I could have tried to assume from other threads that some people really didn’t like larger spreads, and all the discussion didn’t change that, so I won’t say that was the most disappointing part, and so far I can agree to disagree.

But this is something that I really don’t like. In recent custodian grant proposals none of the pool operators except @nagalim chose to at least disclose anything related to the intended spread values in recent custodial grant requests. I don’t mean to make this any kind of a power struggle, which could come at the cost of the Nu network, but I want shareholders to be aware of their rights: if you agree in part to the spirit of this motion, on any one of the following:

  1. users have the right to know the quality standards of liquidity pools
  2. shareholders have the right to negotiate the trade-off between liquidity quality and costs
  3. participants should have easier access to the best options an operator offers

then it may be in your interests to withhold voting for individual LPC custodial grant requests until some of that is addressed explicitly in the proposal.

2 Likes

I agree with every point.

Beyond the details it is my belief that without an effective revenue source and profit model Nu is bleeding its life away holding a vanity zero-spread-after-fee.

2 Likes

I cannot agree more.
Once BTC goes up again, which is the case right now, traders have no problem selling their NBT for BTC immediately since they can do it almost for free besides the exchange fee.
Right now, Nu has no adoption besides being used as a way to hedge against BTC volatility by traders.
So we should make those traders pay for that hedge.
In traditional finance, traders buy derivatives to hedge.
NBT could be regarded as a very simple, efficient, derivative.
Therefore hedging using NBT should be priced via a larger buy/sell spread or offset.

1 Like

Also, I do not think I would have the time to modify the tolerance/offset/spread parameters in the corresponding files. :frowning:
Would it be difficult to ask for an official addition of an offset parameter to TLLP’s bot config file?
Or would it be difficult to impose a higher minimum spread in NuBot?

Put ‘offset=’ then whatever you want in the pool.conf file. Also, ‘deviation=’. If you take a look at pool-bter-cny.conf, you’ll see an example of how I use it (it doesn’t open properly in windows’ notepad program, use anything else).

2 Likes

I agree too, it is no long term solution. However without demand we will bleed anyway. So some investment is required at this time. Keeping a low spread is one way to ‘advertise’ the coin. There is a cost to advertising though. One can argue what Nu can bear and for how long.

1 Like

We have been advertising for more than 6m. What is the impact of that ad campaign?

Nice. Tks. I ll give it a try.
But this parameter only works with your fork of ttlp, right?