[Passed] Motion to regulate spread values for liquidity operations

NuShares Motions
#17

The talk of tolerance is mostly unnecessary except from the shareholder perspective, I’m sorry I spoke of it so much. I hope this isn’t too forward, I was just having trouble explaining it completely:

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=
For all liquidity operations that are paid for with custodian grants, operators shall ensure liquidity providers are not discouraged to provide liquidity up to a specified minimum spread, which we define as the guaranteed spread.

Liquidity providers shall inform shareholders of the corresponding tolerance and give participants convenient options to provide liquidity at optimized values for spread and deviation, such as by having such options chosen by default.

This motion also imposes that the minimum guaranteed spread of liquidity operations between NBT and other cryptocurrencies is 0.5% plus the exchange fee rate. For example, if the exchange fee is 0.2%, then the operator shall ensure that the guaranteed spread is at least 0.7%.
=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

#18

This is a very interesting discussion and one that I want to participate since I have been dealing with those walls full time for one year now.

TL;DR; I agree we should agree on a min-max spread range and force custodians to use that.

Whatever the outcome of this motion will be, I will reflect it in the default parameter used locally by nubot and on the push streaming service.

I think that great part of this discussion is not new and there is some “reinvent the wheel going on” in this thread.

I am not sure we ever had a written contract/rule/motion anywhere obliging custodians to use a specific spread. Its about time we find an agreement on this and I am glad you came up with a proposition. So far spread has always been exposed as configuration parameter from 0.1.4 in NuBot ( I am not sure how it works in the TLLP) and several times custodian changed it to see market reactions. The default spread in nubot is 0.4%, aka 0.2% per side (plus the exchange TX fee, which changes depending on the exchange) .

While I am well aware of the spread problem, I believe the solution cannot be imposing an arbitrary large spread alone. Rather it should be a dynamic market-aware spread (planned in a few iterations of nubot) combined with liquidity distributed around a central price rather than single walls.

That’s not actually true. We are now testing now 0.3.1 and 0.3.2 will come shortly after, most of the work is already there. Anyway, regardless the fact that we have the parametric order book in place, this does not affect your motion about imposing a boundary bid/ask spread. So in this sense this motion is very welcome.

Re OP : your reasoning is correct when you say that we have high cost of maintenance. I find it a bit flawed when you make a comparison with the orderbook of LTC at a random instant of time taking only the top bid/ask. One of the points of NuBits is providing liquidity in a way other coins cannot provide, resulting in outstanding market velocity. Please see some interventions here and here where @JordanLee calls for nubits as an “intermediary coin” thanks to its liquidity operation, along with all my opposition and final outcome. So really, the LTC comparison doesn’t help much the discussion imho.

We deal with three kinds of pairs, grouped by volatility level
NBT/USD (0 volatility)
NBT/FIAT (little volatility)
NBT/CRYPTO (high volatility)
Please specify boundaries for each specific case.

When you say guaranteed tolerance do you mean the bid/spread ask? Or are you saying that sell orders should be placed at the crypto equivalent of 1$+0.07$ and buys at 1$-0.07$ ? In the latter case, its more an offset expressed in $ from target price rather than the traditional bid/ask spread of orderbooks. Wording is important in motions, please edit.

How do you measure the bid/ask spread in percentage btw? In different codes/docs I’ve found at least three different ways to compute the spread and the result is different.
let bestbid be the price of the highest bid and bestask the price of the lowest ask.

 spread1= |(bestbid/bestask) -1| * 100
 spread2= |(bestask/bestbid) -1| * 100
 spread3= (|bestask-bestbid|) / (((bestask+bestbid)/2)/100)

Beside some adjustment to the text of the motion, I think the rest looks good.

Also, please take into account that while I think that setting gross boundaries for the spread is a good idea, the next step is to make the spread dynamic, aka, market-aware.

Comments on other replies

:point_up_2: very correct

So @masterOfDisaster is also proposing a maximum spread for compensation. Is this clear in your motion?

c) in the early stage of a product custodian and the network had to pay a price to comply with the “always 1$” promise rather than “more or less 1$”.

Also here I am getting a bit lost. I am not even sure who is developing what. We had long discussion on price feed/averages/tolerances/sync across exchanges, custodians, etc. Hours have been spent in design and development in this regard. Last time I spoke with creon I told him that we were about to roll out a “push” service that suggests prices to bot (and spreads soon). It is being tested as I type actually, and I strongly believe that TTLP clients should consume this service and be advised on prices (and spreads later). Did someone else took over development of pools? Whoever is working on it, can please make sure that we don’t make (wrong) things twice? This is also at the expense of shareholders.

5 Likes
#19

Ok, that’s really cool. That’s different from the current setup where the client picks the price to put the order up at and I applaud it.

As far as the people running %0.2 spreads being ignorant, I just meant from the perspective of TLLP, where most pools can actually be run with >%0.5 on either side without penalty. If a person is offered free money and doesn’t take it, either they are ignorant of the offer or they are feeling generous. Running with a low spread intentionally for the good of the network at the cost of your own finances is considered generous in my opinion.

I propose a global minimum spread of %0.5 to either side (%1 standard trading spread) for all liquidity operations on currencies that are deemed ‘high volatility’. So if BTC were worth exactly $1, we would do best efforts to compensate sell orders at $1.05 and below and buy orders at $0.995 and above. It’s a little convoluted, because the minimum allows for pools which compensate sell orders well above market price, but I believe such pools will never get a grant proposal passed. This is meant to be a minimum guideline for pool operators, and a requirement that they state what their actual compensated spread is, such that shareholders can use it as a voting parameter.

Maximum global spread compensated should be something like %5, I think, to correlate with legacy.

#20

nope.
There is a misconception here, and it is very important to clarify it.

Even with very sophisticated algorithms, wide spreads, small walls, custodians on crypto pairs are at high risk of losses in term of USD. Custodians will generally be on the wrong side of trades. They will buy NuBits when BTC price is raising , because traders want to enter BTC and leave NBT. Viceversa, traders will buy NBT from custodians when they “feel” BTC price is going down, leaving custodians with a devaluing asset.
This is a fact. The spread can do nothing against it. A 1% spread protects us from instantaneus arbitrage, mispricing , hft bots, bugs. A 1% spread will not protect us from BTC swings that are generally in the order of 5-10% , daily.

#21

I hear you, that is why liquidity compensation is so high. However, keeping the tight spreads that TLLP providers are keeping is certainly not helping.

I don’t think we have an answer for dealing with week to week btc price swings. I think we should make it clear that you should only provide buy support if you think btc is going up week to week and only provide sell support if you think btc is gong down week to week. However, things like this are why my fiat pool is vastly more populated than my crypto pool on bter (among other factors)

1 Like
#22

I though that was what being used and posted to express security concerns . After discussion with @Nagalim I found that TLLP use the same routine to get prices from third parties for both servers and clients, which eliminates the potential security problem. Would pushed prices you refer to introduce the said problem with trusting the server?

#23

I think what he’s saying is that the push service would be a third party to the operator-client deal. So if the push service were compromised, it would indeed be a problem. This is similar to the issue of a compromised price feed, except that we will be creating the push service rather than relying on something like coindesk.

#24

OK. We will see better when it comes out.

#25

8 days ago, I ran nubot, support NuPool and NuPond 14000cny (8.05 BTC in poloniex, 2000 cny in bter), now only 7.92BTC in poloniex and 2000 cny in bter, interest 17.9NBT

Nubot is in operation 24 hours a day, but the funding was reduced to 98.3%

I think that something needs to change, very supportive of this motion

http://8btc.com/forum.php?mod=viewthread&tid=19287&page=2#pid146775

#26

But cannot the custodian make more money than he or she loses because of btc’s volatility, by pocketing the spread each time there is a trade or by combining the pocketed spreads and the custodian fee provided by the pool?
Otherwise, I do not see how being a LPC can become a predictably profitable business. If liquidity provision is not predictably profitable, then Nu would not have any LPCs, hence it would mean the end of Nu.
So it is a crucial matter.

I never try to modify the parameters.
Could you let me know exactly which ones?

#27

These numbers makes sense. I would like to try to shift terminology and instead of calling it spread, we could refer to offsets, sellprice in USD and buyprice in USD .
Offset = 0.05 $ , so we don’t leave anything to interpretation.

Good point, this is mitigated already since the first version of NuBot. Its probably poorly documented so I’ll try to make a very short summary (better documentation coming in next release).

The client-side (old) way (I speak for NuBot) :
NuBot requires at least 3 price feeds (for BTC it has actually 7 price feeds), one of which is considered “main” feed.

  • a process reads the price from these feeds every xx seconds.
  • mainfeed is cross compared with all the backup feeds to check if they are “inline”, within a certain tolerance.
  • if mainfeed is not “inline”, the following backup feed is taken as “main” and the same procedure repeated recursively.
  • at this point we have a “almost good price” . To further check if this is valid or results from a spoof/hack, the bot compares it with a moving average taken in a larger time window. If it pass the test the price is passed down to the trading strategy, if not orders are taken down and wait for the next cycle . If no good prices are found in 60 minutes, bot is shut down and email sent to custodian.

In the new way (0.3.1), we have the price servers doing those operations server side . When the server has a good price (that differs from the previous more than 0.x%) it pushes it to clients, along with an unique auth token.

The client (nubot) receive the command, verifies the token validity, and after that, tries to autonomously read from the third party price feeds to see if the value has been spoofed. If it is within a certain interval of confidence, walls are shifted, otherwise , well a bit of logic also here not worth mentioning.
I hope you get the picture .

2 Likes
#28

There is no way to tell with certainty, only empirical experience, tight monitoring and adjustment can help.
It highly depends on how nubits are used by traders.

In my head, I depicted three kind of traders :

  1. trader that wants to buy/sell small medium amount of NBT to be used for useful purposes. (Buy online, pay someone, loans, betting, parking). I picture these user buying selling in the order of few times a month. These are our ideal users and we want to offer them NBT at a price as close to 1$ as possible to keep them in the loop. These kind of users must be protected and are source of small but positive revenue.

  2. hedging traders. They want to protect themselves from BTC volatility without going into fiat. They buy/sell mid-large quantities multiple times a week. Depending on how good they are with price forecasting, these traders can either bring losses (they are good) or profits (they are bad traders) to custodians.

  3. Malicious traders : traders who have found ways to take advantage of our walls by putting losses on custodians and taking a profit from themselves.

Now, when designing the spread and the bot pricing strategy, we must keep in mind that we want to make user 1 happy, take profit rather than losses from users 2, and mitigate damages coming from users 3. That is what the whole purpose of parametric order book is. Please remember that ultimately spotting those patterns is very challenging and we must be cautions.

A price offset is the easiest short term solution, but long term risks to make users 1 go away and users 2 and 3 getting better at exploiting our walls. Thin ice, the business of liquidity provision :wink:

2 Likes
#29

Thanks for these details @desrever. It is exactly because all this thought has gone into the development of NuBot and the strategies it uses that I want to move towards using NuBot with the TLLPs. A lot of the issues we are seeing with the configuration of the TLLP clients has already been addressed in NuBot and, moving forward, there won’t be a duplication of effort, meaning that the development of the pool server can be focused on.

5 Likes
#30

Just like to add that implementing different spreads and setting on th server site specific to the fees on each exchanges will require a separate instance of TLLP to be run as far as I can see. Haven’t tested running two TLLP threads on 1 server yet but it is difficult with the ports and Cloudflare security. Lacking the time to do that sort of testing at the moment (preparing for Android wallet). Running two servers would make things more expensive to run.
Given the situation/discussion here and earlier outages/issues with LiquidBits/CCEDK I’m considering to continue a bit longer with the current settings or temporarily cease some or all operations on LiquidBits.

#31

Tks for detailing your thoughts.

It probably corresponds to the spreads that dynamically adjustment themselves depending on the market conditions (link).

Could you describe the main principles behind dynamic spread?
In other words, in which circumstance does the bot reduce the spread and increase the spread?
I think this is very relevant to this thread.

I see what you mean but let us say we realize that we are losing type 1 users because of a too large spread.
In that case we can respond to the situation rapidly and decrease accordingly.
So there is not much risk starting at a larger level than now.
We cannot know how the market would react without proposing figures in the first place.

1 Like
#32

Its up for discussion and I wish I can get as many inputs as possible from experienced traders.

In its simplest and intuitive form, the higher the volatility, the higher the spread.
In a more complex form it should also take into account trading activity on the specific pair and various parameters linked to it (average order size, order frequency, day/hour/minute volumes … ) .
In its most sophisticated form, run a machine learning algorithm that learns from experience. This will require more time to aquire training data.

1 Like
#33

Use 1 instance of server.py. I’ve spoken with @woolly_sammoth about this, and we agree it would just take a pretty straightforward working of the ‘tolerance’ parameter out of the root part of config.py and into the individual trading pairs, like volume and rate are done now. It shouldn’t require any extra resources than we are already supplying.

#34

I think in current term pools and LPCs are not bound by the new motion. Maybe the motion should say this.

#35

Thanks for joining the discussion. It is great that developers of NuBot are here to keep us informed. My apologies if my comment on the timeliness of the parametric order book was of any offense.

A 1% spread will not protect us from BTC swings that are generally in the order of 5-10% , daily1.

This is true. On the other hand, speculators as a whole cannot outperform the market significantly and consistently. Under non-adversarial conditions this risk can be compensated for by higher spreads in the long term.

For adversarial conditions (e.g. manipulation) nothing is completely robust. Overall a currency peg is worth protecting if it supports an economy that keeps afloat whatever institution is maintaining the peg, so ultimately this still boils down to a revenue model. To avoid further digression I’ll stop here.

I find it a bit flawed when you make a comparison with the orderbook of LTC at a random instant of time taking only the top bid/ask. One of the points of NuBits is providing liquidity in a way other coins cannot provide, resulting in outstanding market velocity.

I agree it doesn’t conclusively prove anything, and for that reason it may have been somewhat misleading. A larger sample (than 1 snapshot) would have helped, but I think it holds that the observation is alarming. We don’t have nearly the same market cap or adoption yet we try to provide expensive liquidity that is only used by speculators, which calls for attention on this matter.

So @masterOfDisaster is also proposing a maximum spread for compensation. Is this clear in your motion?

I did not include it as I have taken @nagalim’s estimate on a reasonable lower bound, which exceeds @masterOfDisaster’s upper bound. At this moment I am inclined to state that the upper bound is 1.4% plus exchange fee, i.e. a bit over 3% overall spread. I will put it in the motion and see whether people like it.

I agree that ultimately we need to agree upon and implement market-aware tactics on maintain the peg, but this min-max limit as you call it is just a first step.

1 Like
#36

I changed the motion body based on @nagalim’s draft and other comments. I also changed the introduction.

I also tried to address concerns raised by @cybnate to make it easier for ongoing liquidity operations to comply with this motion.

I also changed the title to reflect the changes to the motion draft.