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 :
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.
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.
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
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.
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.
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.
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.
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.
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.
/nu-pool-master/python/trading.py
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.
So the idea is that the more NuBits are exchanged per second (i assume that the more bitcoin price changes frequently, the more nubits are exchanged frequently), the higher the price of using a stable crypto currency should be, hence a higher spread.
Tks a lot.
By the way, i imagine in the next iterations of TLLP’s bot, one would be able to specify directly the offset inside the config file…
As for NuBot, my understanding is that one can already modify the spread (it is not called offset yet) inside the json file but my imaginative interpretation is that if you specify more than 0.2%, you would not be able any more to broadcast liquidity info to Nu.
Is that corrrect?
Anyone with a custodial address can lie about the liquidity they are providing. I could broadcast that I am providing a billion nbt buy side right now.
That is tricky. If not carried out properly, this motion will simply become a “guideline” and turn out to work in a way that @nagalim mentioned earlier, where specific spreads will be decided in custodian proposals. I won’t mind going that way if we can decided that is better for now, but a motion similar to this one will also need to pass sooner or later.
If faster motions are implemented, then when needed we could simply replace this motion with another, if other spread values are desirable. For example, when B&C exchange comes live the lower bound can definitely be adjusted downwards.
We should probably give some leeway if a pool has to change its spread values after securing a custodian grant, where they can choose to explain that change to get the next grant, and we treat it as an exception.
Fine. It also only take one motion to modify this motion, so granting liquidity motion the permission to ask for different spread makes practically no difference. A motion is a motion.
