A motion is only necessary if it isn’t clear the majority of shareholders support this. So, perhaps we should proceed without a motion. If we observe that creates substantial controversy, we can reconsider a motion.
1 Like
I agree. So that is why we cannot afford to wait for the perfect solution. We can start with a good enough intermediary solution first, which that parametric order book mechanism seems to be.
This overall approach of small iterative steps with clear goals does seem the logical path to me. The environment in which NuBot has to work is changes every day in large and entirely unpredictable ways.
It’s nice to have an end goal in mind in the form of the enhanced liquidity motion that passed, but a gut feeling tells me that, in the time it takes to make that a reality, the game will have changed and we will have to adapt to that.
I like the proposed solution from @desrever. It feels like the best of the current implementation, in that the liquidity is clearly viewable on the order book helping give prospective purchasers a confidence boost in the NuBit product, combined with the best of the enhanced liquidity proposal, in that the available liquidity isn’t in the more dangerous zones right next to the peg price, which could deter prospective attackers.
As a next stage for NuBot, I am fully behind this proposal.
1 Like
@desrever and @woolly_sammoth can you divide this proposal into iterations please? Then we will be ready to dive right into the first iteration.
1 Like
I like this plan. It has my support.
I had to put this proposal in context and merge with all the open tickets/proposal we are working on .
The final result is published in this thread (NuBot roadmap)
and here is the breakdown regarding parametric order books :
- 0.2.1 : First implementation of liquidity distribution model (fixed)
- 0.2.2 : Parametric liquidity distribution models (configurable)
[…] - 0.4.1 : Market-aware liquidity distribution models ( adaptive )
We will be basically start working on it right after the release of the current version (0.1.5) .
2 Likes
An update on this : we have prepared the infrastructure to design the order book, visualise it, place the orders, etc. It is not integrated with the bot yet, and from early testing it emerged that we will face challenges : moving around large number of orders can be a “painful” operation since most exchange’s API require to cancel and place orders one by one. So shifting a “simple” order book with 5 orders per side, requires a minimum of 20 API requests . I have been pushing on exchanges to implement an entry point for clear all orders and placing multiple orders with one call. On Peatio it is already available, I suspect that exchanges will need to adapt to this sooner or later, but currently this is a bottleneck.
For nubot to deal with current slow and suboptimal exchange’s API, will require implementing parallel concurrent requests (and that also is absolutely non-trvial, since the nonces are uniques and incremental).
Stay tuned.
1 Like
What do you think is the likelihood of exchanges implementing the changes you’re asking for?
Not sure if Altcoin exchanges will allow for this because they still have to process the orders on their end.
If I look at your nice picture its actually never 5 at once that need to be replaced. An order shift is required if the $1 mark moves too close to the nearest price bin and in this case this price bin has to be replaced (e.g. at the end of the curve), which are 2 API calls. Afterwards you are not in urgent trouble anymore and you can slowly over time rebalance the remaining orders such that you can reshape your order book.
That won’t even help you if the exchange API just let’s all but one requests time out. The TLLP is doing parallel requests, where the nonce is secured through thread locks. This works fine, as long as Cloudfare and the exchange server is friendly.
I wonder if B&C would allow us to get around these roadblocks.
1 Like
Not always, It depends on the spread and order density. A 1% BTC/USD price change could require taking down all orders at once. And this is also why we want the spread to be dynamic , and wider when volatility is high.
Let’s see
1 Like
Is dynamic spread setting a part of the parametric order setting planned by you?
In any case, i do believe that having a dynamic spread that varies according to volality is crucial for making liquidity provision a predictably profitable business.
Right now, lpcs provide liquidity to traders for free although it s clearly a real value proposition. Current lpcs are totally exposed to btc volatility and that is why there is no guarantee that they will be in the black. When i think about it now, liquidity provision is the first and main service of Nu right now and yet it is offered for free. Why? This topic should be probably in another spread.
Yah, dynamic (and asymmetric) spread is intriguing. It requires server side changes though, because as a client we should be using the absolute biggest spread we are allowed to (most of the time). That’s why I’ve been running my bots with a .7% spread (1.4% between my buy and sell orders).
Most other lpcs lose money if they get shorted for any amount (due to exchange fees). If I have prefunit turned off, I only really lose if I get shorted for >1%.
Also, prefunit is already a step toward a parametric-like orderbook and Creon’s concept of liquidity bands with different compensation would also promote such a dynamic and multi-valued order book for TLLP.
it is, and it is called “market aware adaptive order books” in the roadmap 
1 Like
this: “0.4.1 :
Market-aware liquidity distribution models ( adaptive )”
I believe this feature would be extremely important if we want to increase drastically the number of LPCs and therefore perhaps deserves to be implemented in priority. What do you think?
While I will take inputs on the urgency, there are some items that simply cannot be implemented before others for technical reason. This is one of them, and it depends on reaching previous milestones.
Tks for your answer. Got it.
How would B&C respond to those 20 API requests?
Just bumping to say that last issues are being resolved and current release is practically ready. Tomorrow I will start live testing of 0.3.2 which implements the first version of parametric orderbooks.
It’s going to be fun, stay tuned
4 Likes
That’s great!
I understand that this will be very much needed for BCE.
It seems that currently except for NuLagoon no liquidity operation uses NuBot and can make use of it, right?
I miss integration into ALP (formerly known as TLLP) on the NuBot development roadmap, that was sketched like this:
Are there plans of providing ALP with parametric order book capabilities?