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?
Oh yes, we did found a solution for creon’s demand which allows third parties to interact with the bot’s configuration parameter via API, at runtime.
3 Likes
Awesome!
very very poorly documented [here][1] . Will refresh this documentation once 0.3.2 is out
[1]: https://bitbucket.org/JordanLeePeershares/nubottrading/src/450dd974e35756bbb83773d4ee5e8b40d2add8c5/docs/API.md?at=master&fileviewer=file-view-default
It seems that the documentation has been included into doc.nubits.com recently. https://docs.nubits.com/parametric-orderbook/
Nice.
I took a look at the OP’s date: January 2015.
Almost 9 months have passed…
I suppose this is the amount of time required to develop such a sophisticated bot behavior.
I have a question that might sound naive, at this stage. I assume that the goal (G) of a parametric order book is to avoid putting all the liquidity into one single order price so that a rogue trader is prevented to access a huge amount of cheap liquidity in a single order. So what the bot would do is to spread the liquidity over different order prices that go higher and higher on the sell side.
When the least expensive sell side order is filled, the bot would shift down the next sell side order to the least expensive sell side order position.
But this will not prevent a trader to eat up all the sell orders book rapidly.
The difference is instead of letting him or her do it in a single order, the bot will force him or her to do it gradually but at the end (G) is not accomplished.
Am I wrong in my understanding?
Sorry for letting you wait, but before that we had to clear previous items.
The implementation/design started on 2015-07-22 with this commit and the first release candidate has been tagged on 2015-09-21 (0.3.2-RC1) .
Considering holidays august in the middle, that’s more or less one month + of part-time development
You made a very good question and also have a good comprehension of how it works. This week we should be done with testing and I will spend decent amount of time explaining how it works and what’s next, so you’ll get a better understanding how we will go towards (G)
1 Like
Wo. That is rather very quick. 
Really looking forward to it.
Impressive…!
NuLagoon and mod puddle?