[Passed] Motion to regulate spread values for liquidity operations

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

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?

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.

OK. We will see better when it comes out.

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


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?

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 .


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:


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.


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.

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

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

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.

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

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

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.

I hate to keep you revising over and over, but I think @desrever had a point with using language like “offset” instead of spread.

I also think your maximum offset is low and would prefer %5, but that’s not a dealbreaker for me.

1 Like

Sure, neither is 5% a dealbreaker for me, and I’ve noticed that I have also missed a few more things such as specifying USD or Fiat spreads limits. I’ll do another revision later.

Maybe add a line that a liquidity provision proposal can request any spread for shareholders to approve on a case by case basis, for situations we can’t now see.

1 Like

Change line 41, way over on the right, the deviation, to 0.0015. You can also change this in pool.conf, but it’s just as easy here.
Change line 207, the spread, to 0.005.
Those values should work on all servers but the one on bter’s fiat. I think, I don’t actually know other operators’ running parameters.

DISCLAIMER: If you lose money it’s not my fault.