Modelling a parametric order book

Currently NuBot puts all the available liquidity in a vertical wall, according to the initial design outlined in the whitepaper. The above model worked out to well to prove Nu’s capabilities of pegging, but now it is time to move forward.

Many new hypothesis emerged around the next direction, and here I am, trying to make a synthesis and put them together into something more concrete. If you haven’t done yet, I invite you to read past (long) discussions : one - two - three .


The option that I personally prefer, is to use a parametric model to distribute the liquidity offered by the custodian around the center price of 1$.


This afternoon I prepared a proof of concept parametric model to help the discussion and gather ideas.

  • The model can be configured by the custodian using the configuration file.
  • The model is dynamic, in the sense that its parameters can be manipulated at runtime.
  • I imagine NuBot capabilities to autonomous adapt parameters to best fit market conditions.
  • The buy and sell liquidity can be modelled separately

The image below is a graphical representation of the model proposed.

Parameter,Description ,Accepted values
offset, distance from 1$ target price, USD 
wallHeight, amount of base-liquidity available at the best price, USD 
wallWidth, total width of the order book, USD 
curve:type, type of model, lin-log-exp 
curve:steepness, steepness of the curve, low-mid-high 
density, distance between orders , USD 

Below, a sample JSON representation of the model, to add to custodian configuration file.

{"options": 
    {
    "sellSideLiquidityModel": {
      "offset" : 0.1 ,
      "wallHeight" : 200 ,
      "wallWidth" : 0.5,
      "curve" : {
        "type" : "log",
        "steepness" : "mid"
        },
      "grain" : 0.02 
    },
    "buySideLiquidityModel": {
      "offset" : 0.1 ,
      "wallHeight" : 350,
      "wallWidth" : 0.3,
      "curve" : {
        "type" : "exp",
        "steepness" : "high"
        },
      "density" : 0.02 
    }
    }
 }

The model is simple and at the same time flexible enough for making it fit in different market scenarios. It is a first step toward the future direction.

I would love to gather inputs from the wise community and bring the discussion forward.

EDIT: ideally NuBot should be able to read the existing order book and adapt the offer to it, such that the resulting order book is as similar to the ideal shape as possible.

7 Likes

Yes,right~

This is an intriguing idea.

@desrever do you see this as an intermediate step to the currently planned order book mirroring or as a replacement of it?

It is much simpler than what is planned, which is useful. However, it would alternatively provide either less liquidity than order book mirroring (with pricing that is too high) or more liquidity than order book mirroring (withing pricing that is too low, exposing the custodian to loss). The depth of order books changes rapidly, especially on illiquid pairs, so this would rarely mirror those accurately. Maybe it is alright to offer more or less liquidity than the open market, so long as on average a little less liquidity is being offered by NuBot than exists in the market. @desrever, what is your view on this last point?

Would there be a useful role in automatically changing the curve values to encouraging balancing the available liquidity? In essence, if the sell side has less liquidity, steepen it while while making the buy side more flat?

2 Likes

An intermediate step.
The final goal is maximise custodian’s pegging capabilities while offering fair liquidity. The road to the goal is iterative and explorative, and I see the parametric model as a starting point. I’m not able to see the top of the mountain from here, and I don’t know what’s on the top.

Indeed, the second logical step would be make the model adaptive.

The more flexible the model, the better we can emulate other order books by changing parameters in runtime.

Definitely! This is a very good example of what I have in mind when saying “adaptive” model.

1 Like

Progress is being made here. It’s good that there are many tune’able parameters. The problem I see, in general terms, is that it may offer too many parameters that don’t have an immediate apparent relation to what the custodians observe, and these parameter don’t seem to be orthogonal, meaning that changing one will affect the choice of others.

I think we need to define a goal and a quantified measurable performance figure against the goal. Tuning the wall is maximizing this performance. Then we provide (hopefully orthogonal) tuneable parameters which the custodians could change and cause the performance of the walls to change. By iteration (assuming the parameter space doesn’t have local maxima traps), trying a grid, or simulation we can either find optimum parameter settings or develop rules to set parameters according to conditions.

So I guess the first question is what is the goal or what are the goals?

@desrever, how much time do you think this would take to implement as a ratio of the time you think the current order book mirroring plan passed via motion will take? A quarter as much time? Half? I think improving our liquidity provision quickly will be one of the most important factors in how Nu fairs in the coming months. This may be a good idea as the next step. I would like to see it brought to a motion vote or rejected after further discussion. I would rather not see it forgotten.

2 Likes

Between a quarter and a half.

I agree, this is very high priority and the next logical move in NuBot evolution. Is it necessary to prepare a motion? The proposed changes will not affect current nubot behaviour : by tweaking parameters is still possible to custodians to offer a single buy/sell wall. This change is reversible (by setting a configuration parameter to false) and can be seen as an additional functionality rather than a protocol change.

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.