Finalized evolution of liquidity operations

Thanks @JordanLee for taking the time to expand on the enhanced liquidity operation with some figures. It has cleared up most of the concerns I had around the reasons for doing so when such a large change to the technical workings of NuBot is required to achieve it.
My remaining concerns are less to do with NuBot itself although they do echo @Cybnate s concerns above.
When working with NuBot, and previously with personal trading bots, the weakest point has always been the APIs of the Exchanges. While they perform admirably 99% of the time, the 1% when they fail (or communication with them fails) is when the market has most movement, which is just when you need them most. I’m less concerned about NuBot instances not being highly available, more the APIs, which are, unfortunately, out of our hands.
Although knowing this to be the case puts us on a good footing, a lot of thought needs to be paid to the best ways of reacting to such an API failure when it could impact the mirroring and overall liquidity provision so badly.
The actual implementation of reading orders, doing a calculation and placing a similar order somewhere else should be fairly straight forward. It’ll take time but the code to interact with the exchanges in that way is already there in NuBot, it’s just the controlling logic that needs a tweak. I’d agree that an extra developer for NuBot would be a good thing. As mentioned, I don’t always have the spare time to devote as I would like due to other commitments.
I do think though that before that, there should be a wider discussion among shareholders around the controlling logic of NuBot and how to react to the various scenarios that have historically played out in the real world. I’m constantly astounded by the level of trading knowledge displayed on this forum and feel that it’s a hugely valuable resource that needs to be tapped for the Nu trading bot.

My other concern is around the number of Custodians we have versus the number of markets we will potentially have to mirror. I’m comfortable with the idea of a single custodian potentially handling the mirroring of an entire exchange on a second, with all the pairs that entails. I’m also comfortable with the idea of a single custodian potentially running multiple instances of NuBot to cope with that. There comes a point though where we hit a natural limit both in terms of what a single custodian should be expected to handle for the return they get and in what a single NuBot instance can handle with mirroring.
I’m not really expecting an answer to this as we will only find out what those limits are by trying out various combinations in the real world and seeing what happens. I write it here as a concern merely because that’s what I started thinking about when I read Jordan’s example. At least it’s now a known unknown!

In conclusion - I’m sold on this idea now. I think this is a logical evolution for liquidity provision to take and, now that my concerns around it have been allayed, I’m excited by the technical challenges it presents. I’m going to crack on with implementing as many APIs as I can find.


Could someone explain how we end up with “using NBT cheaper than using USD”?
I fail to understand the calculations.

In any case, it seems that in the overall vision of @JordanLee, besides monetary policies, developing and maintaining NuBot than can deal with multiple pairs over different exchanges is a crucial element for maintaining the peg, therefore for NuBit.
At the same time, it seems that NuBot would get more and more complex as well over time.

So I agree with @cybnate on the fact that providing max transparency of how NuBot works is of utter importance not only for shareholders but also for users.

It is easy to be tempted by the dark side of greed and try to take advantage of a centralized system that you have control over. Have a look at what has been found out with MtGox. It looks that Mark created fake trades all along, to build up more than 600k bitcoins in his own pocket.

The best way to make NuBot transparent is to put it somewhat on a blockckain-technology, I believe but is it realistically easy to implement? If the answer is yes, what would be the cost to shareholders?

Besides, if this motion passes, by when mirroring is intended to be implemented?

EDIT: I have understood now how the computations are made.

1 Like

I am analysing the proposed approach and taking some time to thinking this through.

We can definitely use an additional developer time for implementing the “move funds across tiers” part while I work on the mirroring part.

It is very interesting reading about all the different point of views and expertise in the community to form a more holistic vision.
This is why I am also interested in reading more about the concerns expressed by @mhps, and also listening to the opinions of more experienced traders ( including @Chronos and @pennybreaker :wink: ) .

While we will do our best to incorporate collective wisdom into the bot, I have a strong feeling that one of the best way to achieve good results in this domain is empirically.

Once again I want to express a wish : while 3-4 persons, including myself, are working on this experiment, I would like to see the rest of the community trying to explore other domains where a digital 1$ currency comes to hand. In case our experiment fails, we should have many other open branches to work on. I invite everybody to read Jordan’s last post about vision and mentally replace “intermediate liquid currency” with some of the many spaces we could attack : crowdfunding, remittance, merchants, crypto-equity, betting … Sorry for sounding redundant .

1 Like

This motion passed 1 day ago.
@JordanLee Hope you will address some of the concerns though.

1 Like

It is definitively one of the huge application domains of NBT, I guess once we have established a deep liquidity across exchanges.

I submitted some proposals to improve NuBot to the developers. I believe there is a lot of room for improvement it will be interesting to see how it evolves.


In the near future, i imagine users charging their NBT virtual wallets by just making an order with their credit cards, There will be also NBT prepaid cards…

I note that even if Nu cannot get a special discount and has only 0.2% instead, it is still cheaper overall to buy cryptoassets with NBT instead of USD.

My opinion is that we should not have liquidity at all in any other pair than NBT/USD. Not even NBT/BTC

Nubits works for USD because both NBT and USD can provide practically unlimited liquidity, and changes in USD price are so small that are more than enough to be covered by the conversion fee.
But when we create walls in a volatile currency like BTC we are exposing ourselves to that currency liquidity, which is, like its price, totally volatile. We are effectively injecting liquidity into other volatile currency, trusting that price is volatile but liquidity is not, which is a big misconception.

Sure, some may argue that bitcoin have, let say, 200k BTC (a ton) in liquidity at current prices at both sides, the bot can rely on that and place walls accordingly.
For example a bot with 1k BTC and 270k NBT: when someone dumps on it 1000 BTC and leave the bot with 2000 BTC / 0 NBT, we assume that we can sell the 1000 BTC back. But then we are relying on the bitcoin liquidity to remain the same. What if the 200k BTC liquidity have been consumed? Then the price moves and the bot lose money. This can happen in any currency without that practically unlimited liquidity. It is happening in PPC, could happen in BTC and any other crypto.
Sure, it works for now, but who wants to rely on something that can be exploited any moment?

So my vote would be to leave only NBT/USD.
But what happens then if someone wants to convert PPC to NBT? The answer is multiple conversion, hopefully operated by an exchange.

This works like this (like a single transaction on the exchange):

  1. User 1 have 10k PPC and wants nubits. PPC price is 1 USD.
  2. The exchange locks the user 10k PPC.
  3. The exchange look at PPC/BTC liquidity which is for example 12k ppc at 0.003. Ok, the exchange can put here 4k PPC and get 12 BTC but the exchange does nothing yet.
  4. The exchange look at PPC/USD liquidity which is for example 6k ppc at 1 USD. Ok, the exchange can get rid of 6k PPC and get 6k USD but the exchange does nothing yet.
  5. The exchange look at BTC/USD liquidity which is for example 20k USD at 300 USD. The 12 BTC that we could get on step 3 could be exchanged for 3600 USD.
  6. 6k USD of step 4 plus 2400 USD of step 5 sum 9600 USD
  7. The exchange lock orders at 3,4 and 5, execute the conversions, and get the 9600 USD
  8. 9600 USD go to the NBT/USD pair for 9600 NBT and the user gets 9600 NBT

This can be calculated by the exchange in real time, and show the user how many NBT it would get with his 10k PPC. Using REAL liquidity and getting the price accordingly with both the available prices and liquidity.

Also, NBT would be tradeable between any currency without any risk for any party.

Wait, but if 1 PPC is 1 USD (or 1 NBT) then 10k PPC would have to get 10k NBT. Why am I getting only 9600 NBT?
Because with the current price and liquidity of PPC the real price for selling 10k PPC is 0.96 each PPC! We can’t have a wall in NBT/PPC at 0.96 NBT/PPC because we do not control price and liquidity of the PPC market.
The price for NBT/PPC would completely change for someone selling 1k PPC and for other selling 50K PPC!

This would be adjusted by fees but I am sure you agree they would be insignificant. Also the exchange offering this service should not charge the fee in every step of the conversion, only in the final one, maybe a little higher because of the processing but also insignificant. There is not any risk for the exchange.


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 .

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

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

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)

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)

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


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


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



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?