Finalized evolution of liquidity operations

Very interesting. Hope you have read the discussions here.

Here is the first part of my reply. I will focus on analysing the merging part of the proposal, where I see two main problems.

In the reported example, the way in which the liquidity is replicated, looks like a linear sum of the order books.

I think that this is sub-optimal, at least in regards to protecting custodians from the “illiquid junkcoin attack” that triggered this discussion.

In fact, to replicate order books by using a linear sum of all the order books available, we are multiplying the liquidity, not mirroring it (first problem). The custodian will need a very large amount of liquidity, far superior than the mirrored book on average.
Imagine the case where Junkcoin is available at 10 exchanges, and say that the average depth of the order books on each exchange is 7 BTC. If we mirror using a linear sum we are offering a liquidity of Junkcoin that is ~ 70 BTC. Which is equivalent to offering a quick way to exit illiquid markets faster, that is something we want to avoid, isn’t it?

Second problem I see : just by looking at @JordanLee example, it may seems that implementing it into nubot will be straightforward, but I can assure that is not. The example you have done is static while order books sometimes changes multiple times per second. This will make the mirroring so unstable that we will end up with the majority of orders being in a constant “cancel and replace” state. You should provide some more realistic time series of order books to allow me to comment properly.

As for now, I see it so unstable that I believe it will be very hard also with a single order book due to exchanges APIs . Here is why (re-iterating a BitMessage conversation) I believe this cannot be stable :

  • It makes the whole system depending on multiple third parties data that we do not control in any way. This adds several points of failure and possible attacks.
  • Delay are killers: remember NuBot is not directly wired into the trading engine : it is just pulling data over http API using the exposed API (a few now offers websockets streaming, which is better).
  • Most exchange’s API process orders one by one, there is no way to cancel and place a large number of orders continuously quickly enough to mirror a fast-paced order book and not being banned by the exchange API.
  • Mimic real time orders execution is far from reach. In a fast paced markets orders are filled and entered very quickly. To simulate an order execution, nubot should : a) detect a a trade(s) happened (order book changed. This read operation can be executed realistically every 5 or 10 seconds or we will get banend- b) recompute the new order distribution - c) cancel old orders and wait (the cancel operation is async, since it might fail if an order if frozen or being executed) - d) is the order canceled? e)place the new order. I bet that by the nubot went through this process, the order book looks already different. We will end up with a very unstable mirror.
  • How to deal with large buy and seel walls that are often placed to manipulate the market in one direction elicitating fear/greed?
  • Lets talk about possible attacks : once everybody knows we are mirroring, say, btc-e ppc/usd, people can freely manipulate the order book over there to obtain the same liquidity configuration on NBT.Fill the order fast on NBT and delete it the ppc/usd order right away. This is not a double fill, it just require one trader to place orders on the book, wait for our bot to mirror it, and then buy/sell into NBT.

I also have other concerns about wall collisions, but I do not want to discuss them until we go around the above-mentioned problems (one and two).

Enough with problems, now with the solution . The more I think about it the more it makes sense : models,models and models.

A very dumb example of model using @JordanLee example’s order books. Let’s see we are “watching” (not mirroring) three order books .

Bitstamp
Price, USD, BTC
310, 620, 2
311, 933, 3
313, 1252, 4
315, 630, 2

Bitfinex
Price, USD, BTC
314, 942, 3
316, 632, 2
317, 317, 1
319, 1595, 5

BTC-e
Price, USD, BTC
308, 924, 3
310, 620, 2
312, 624, 2
313, 1252, 4

Dumb example, bare with me.

First thing is deciding the depth of liquidity we want to offer - which cannot be imho the sum of all the other order books.
step1: lets define the price range in which we want to offer liquidity by removing extremes values (high and lows) : say, from 311 and 315 .
step 2: for each market, take all the orders in that range and sum the liquidity available. Then make a weighted average to obtain the depth we want to offer : the result of this calculation is , say (approximately) 6 BTC.
step 3: so now we know we want to offer a total liquidity of 6 BTC. We should decide how to distribute them around the center price. Let’s apply a linear “V” shaped model for liquidity (angular coefficient q = 1.2 , a 0.5 price increment ). Here is the resulting order book (buy side)

bter
Price, BTC, NBT,
311	1.07	334.31
311.5	1.05	327.08
312	0.90	279.49
312.5	0.75	233.28
313	0.62	194.71
313.5	0.52	162.52
314	0.43	135.65
314.5	0.36	113.22
315	0.30	94.50
		
Total	6.00	1,881.06

Now, for the sake of the example lets do the same for the sell side. Let’s say there is a much deeper liquidity in the market on the sell side then in the buy side: ~20 BTC. here is another linear order book for the sell side (q = 1.3)

bter
Price, BTC, NBT,
315.5	0.50	157.75
316	0.65	205.40
316.5	0.85	267.44
317	1.10	348.22
317.5	1.43	453.41
318	1.86	590.36
318.5	2.41	768.67
319	3.14	1,000.84
319.5	4.08	1,303.13
320	5.30	1,696.72
		
Total	21.31	6,791.94

Lets draw it , just for fun :

Here we go, we have a clean stable order book computed using market velocity data. We are not offering huge buy and sell walls. We are mitigating the illiquid JunkCoin attack. We are offering a very good liquidity. We are making profit from big orders. We are not depending on third parties much. We are less subject to order books manipulations. We can allow multiple custodians without any collapses. LPC will not need to open an account on several markets. (and the list continues)

We can parametrise the above model in many fancy ways. I just wanted to illustrate the simplest example for the sake of the conversation.

Would like to hear some thoughts

6 Likes

Second part of my response, commenting on the second part of post 86, starting from :

I am having an hard time understanding this example, and especially how does it fits when compared with the first example. The word “mirroring” - in my head - involves re-creating an exact copy of something by mimic it. In the example below, we are altering the source (BTC-e market), not just “mirroring” it.

When one of his orders on either CCEDK or Bter is filled, NuBot executes a comparable market order on BTC-e immediately.

Why would we do this? This seems to me a different scenario from the one you depicted in the example at the top of your original message, where nubot passively combines three order books into one. This last scenario seems like nubot should attempt to recreate “uniform order books across markets” instead of mirroring one (or more) source(s) into one.

Could you clarify this last bit?

1 Like

As long as we support NBT/crypto on multiple exchanges that were not built for high frequency API access, there will be an attack vector that no amount of creative problem solving on our part will ever solve. NuBot will always lag the market. This means that a trader can observe a price breakout (or breakdown) on other exchanges and they have up to two whole minutes to fill their order on NBT/crypto pairs before NuBot makes a price adjustment. Two minutes can be an eternity in this game. It’s like giving the public a vehicle for non-stop insider trading. The only way to address this problem is to:

a) Remove custodian support from NBT/crypto pairs

or

b) Create an exchange that is built around super high frequency API access (Wall St. style) and only offer those pairs on that exchange.

pb

5 Likes

My overall understanding is that this will be done gradually.

This doesn’t change anything. It’s an arms race. Other traders could also take advantage of the fast access to trade against nubots.

This is true unless it’s intentionally set up so that NuBot front-runs everyone else.

I think @desrever proposed a good first-step to create a synthesized layered wall prices. The center of gravity on each side are naturally separated with a wider distace than the tightest spread on the market, which is good.

The question in the follow-up post should be answered, although if not all markets whose prices are used in calculating the wall have nubots deployed (e.g. if you use btc-e price but don’t plan to deploy a bot on btc-e) the problem doesn’t come up for the undeployed markets.

For those markets that do have nubots, the “a comparable market order on BTC-e immediately” Jordan referred to I think could be understood as the result a series of events,

  1. The nubot recalculates the layers of price-vol pairs becuse “one of his orders on either CCEDK or Bter is filled” (for a simple example someone just bought 100BTC’s worth at price=123 on ccedk. So the calculated wall has “sell 30btc at price=122.2” removed.),
  2. Bots move walls on all exchanges including btc-e according to this new layers,
  3. For traders on btc-e, it’s like some order is filled (as in the example above, the order book had a sell vol of 50btc at price=122.2 and now it has 20btc at 122.2)

In any case I think combining order books takes bigger leverage on available liquidity if unchecked.

1 Like

Unless you have multiple such exchanges willing to do this for nu (why?) you have centralized operation.

Hi @crypto_coiner

I couldn’t find the details for the Mustodian Vote on 65CB60D096508A7FA9ECC2017B38BC3AFEB5663D:

Any progress on book order mirroring?