Exchanges and risk in NuBits

I have studied the NuBits system and have some comments.

I think the interesting idea with NuBits is to establish a network between exchanges. That is a novel and valuable idea. While it has some resemblance to existing topologies, it’s quite a different approach.

I believe it would be much better to license the code as MIT, not GPL. That should be standard in all crypto-projects IMO, because GPL creates road-blocks between commerical and non-commercial entities. For example an exchange would be unwise to add code to NuBot’s code base, because it can’t then re-use contributions. Which makes exchange software and NuBot incompatible. Currently that might not seem so relevant, because exchanges provide no infrastructure to clients - but that will change in the future.

Some points on risk and liquidity:

  • As far as I understand the spread is assumed a constant determined by shareholders. However the profit-potential of one LP is not a constant. It depends on volume and perceived risk. If one LP’s evaluation of risk changes he ought to be able to adjust the spread to reflect higher or lower risk in the system.
  • The risk is assumed to be only counter-party risk against exchanges. There is much more risk against the NuBits system itself (systematic risk, not counter-party risk). If for instance a major LP defaults, then the risk spreads to other LP’s, pretty much instantly. With high risk of default, a ROI of 5-10% would not reflect that risk. ROI needs to be determined by the market to reflect individual assessment of risks. Effectively NuBits are also Credit-Default-Swaps of Exchanges.
  • An interesting variant would be if LP’s would be able to post collateral of some kind. Just because many LP’s exist does not mean that the risk is spread. LP’s basically issue IOU’s via the network (LP layer > network layer). The ability to maintain the spread comes at a risk of default (on both layers, similar to the banking system where the central bank is lender of last resort).
  • Essentially the NuBit system is an inter-exchange note, similar to Ripple/Stellar. The innovation seems to be that gateways are not centrally controlled. I believe its not clear how the trust in any one gateway is justified. Bitshares tried to establish a delegate system, and has run into this issue - trust in a party depends on clear identity (Sybil attack). In NuShares I’m not sure it is possible to know whether all LP’s are not really one person printing money. It’s quite similar to the problems pure Proof-of-stake systems face at IPO.

From an exchange perspective it would not be good to become an LP (independent whether it would be profitable to do so). Exchanges have to be neutral with regards to the currencies. There seems to be an opportunity to integrate the different exchange API’s to one common infrastructure. For example a trader might want to hedge exposure against one exchange, or move balances from one exchange to another in a seamless way. Currently all exchanges basically have their own API’s and there is no common ground. Basically NuBot could be built on something similar to Xchange ( - a common framework/wrapper for all exchanges.


Hi @benjyz , nubot dev here. Thank you for your valuable feedback.
As you can read in the roadmap, cross-exchange LPC operation will be a reality sooner than later.

0.7.1 : Liquidity balancing across markets

I like the angle you used in your post to delineate the future scenario.

Xchange seemed also promising to me when I started, but I ensure you it is not worth the effort : more than 50% of their wrappers are obsolete, poorly written, missing the private API part and allow for little customisation.

The current trading bot uses a custom trading interface which is easily implemented making nubot adaptable to new exchanges, with a lead time varying from a few days to a week.

1 Like

Right, XChange is not well implemented. Once one gets into things like synchronizing orderbooks and making decisions on lower latency level, there are a lot of challenges. Exchanges so far don’t really give any promises to the latencies on the backend, and then there is the uncertain latency from client to server. Which makes routing orders on the micro-level unpredictable. Theoretically liquidity will flow to the fastest exchanges. If all exchanges would be connected in some way, then one would have proper uniform pricing. But for BTC/USD that’s not possible since bank transactions are reversible. Whether a pegged currency (/IOU currency) can bridge the gap will be interesting to see. It’s more realistic than exchanges becoming gateways. Bitstamp is a Ripple gateway, but I think nobody uses it.

What would be needed to make the best trading decisions is a data repository of the current and past state of the orderbook, i.e. a database of each orderbook and then a global aggregated orderbook. H2 is a nice SQL database which can be used without configuration.

1 Like