Modelling a parametric order book

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 :wink:

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


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.



very very poorly documented [here][1] . Will refresh this documentation once 0.3.2 is out

It seems that the documentation has been included into recently.
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 :wink:

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. :smile:

Really looking forward to it.

See announcement of NuBot 0.3.2 release NuBot releases