NuBot priorities and multi-tiers management discussion

Continuing the discussion from Draft motion to end LPC operations of KTm, Jamie and NSR sales of Jordan:

Replying with a new thread to avoid mixing topics.

This can be prioritised over other some other items, not all of them imho. Priorities are very hard and we are doing our best. We all need to be a bit more patient or we risk confusing development.

I am accumulating pieces of the puzzle and trying to put them together. It’s an hard task and I am trying to keep the global vision despite being wired at low level inside nubot development.

I give you an example : one week ago we assessed that a problem of getting custodians was the difficulty of running nubot.You asked me to make UI a priority, which I did, and @benjyz is already working on the implementation because that was high priority.

With tier 3 liquidity implementation the custodian will need to safely run two 24/7 hotwallets and configure them to speak with nubot via RPC. With all the respect, this is not an easy task and will make configuration and setup so much slower that it is almost incompatible with the requirement of having an “user friendly bot” with a wizard setup.

With that being said, this is now my job, and I will do my best to accomplish it.

Today I stopped development of the distribution model of liquidity to focus on this, and I am preparing a motion to respond properly, I expect it to be ready tomorrow, if not later today.

A small note on the scenario you described (added two asterisks) :

if by side ** you meant sell/buy, this can only happen if custodian loses its overall usd-equivalent value (or if she withdraws funds) . In a normal situation, if one side gets low, the other gets big, they are strictly related.
Tier 3 > 2 movements should be triggered on a per-side basis separately and require sophistication .
The trigger should NOT be punctual : we have seen traders trading back and forth multiple times per hour. if the bot detects that at a certain point in time NBT (or BTC) tier 2 liquidity is lower than a threshold, that cannot represent the only signal to trigger the NBT (BTC) deposit. If you add on top of that that BTC deposits can take up to one hour, its easy to understand that the technical solution must be (ideally) designed with some smart AI and machine learning (ML), or it will likely fail or at least perform worse that a custodian doing it manually twice a day.

Oh you made an UI? That’s awesome. I started a little bootstrap project yesterday to create a web UI that manages the json files, but its nice to see that something more professional will be implemented.

I don’t really see the problem in your scenario. In the worst case the NuBot will send Tier 3 liquidity in form of X to the exchange although the market will rebalance the walls automatically after a short while. After the walls are rebalanced and the additional funds arrived on the exchange, the NuBot will recognize that too many funds are in Tier 2 and will send some of those back to Tier 3. So its only a small time window in that too many funds are on the exchange.

Correct. Indeed that’s a good start.

There are two problems with this, and one doesn’t have a straightforward solution : Only a minority of exchanges support withdrawals. And even for the few that do support withdrawals, its quite an hazard for the custodian to give withdrawal permission to the apikey. And personally I wouldn’t do it, even when its me writing the bot.
Our design will still require manual withdrawals (oh yes custodians, more work for you!)

1 Like

In this post I propose how the NuBot short/mid term roadmap can be modified for dealing with new evolving requests. There are a couple of changes that will not only affect the way the bot it is developed, but also liquidity provision.

Tier 2 Proposal :

Tier 2 currently sits on the exchange in the balance of the custodian but not on order. It is used to quickly fill the tier 1 poll when the active order gets executed. Tier2 funds are at risk of exchange default and thefts, therefore we have to make good use of them. I believe there is a better way to put tier2 at work while serving the purpose of quickly refilling tier1.

I propose to offer tier2 liquidity in the market at premium price, and distributing it according to the liquidity distribution models we have been discussing in other threads.

When the green tier1 wall is consumed, the bot will replenish it after a N seconds delay or at the following price shift, with N becoming function of market activity in the future. This will allow to have a continued offer of liquidity on both sides. It will require little change in the code (the liquidity distribution is being tested as I type). It will allow large sellers/buyers to have their market orders filled immediately if they need to , and as a side effect, will make a profit to the custodian.

This affects the tier definition :

Tier1 : Amount of liquidity offered at the best possible price (1$+fee+spread)
Tier2 : Amount of liquidity offered at premium price
Tier3 : Amount of liquidity off-the-exchange, hot wallet

Note: In the future we can also have a new tier layer that stays on the exchange (in a different account to spread risk) , not on order, which is used to rebalance buy and sell by filling an order, with no need to wait for BTC confirmation time . More on this in the future, back to the short/mid term development roadmap.

Tier3 Proposal

Development will spitted in three incremental releases.
In the immediate release (0.2.1) the whole nubot team will work on building the base blocks to allow tier3 liquidity management.

While I will focus on liquidity distribution (tier1 and 2) ,@benjyz will work on NuRPCCoinClient : an Implementation of a Java RPC Client to communicate via RPC with crypto/client and expose the following methods

 - void initClient (cointype, ip,port, rpcuser, rpcpassword, encryptionPassphrase) 
 - boolean isOnline () 
 - boolean isEncrypted () 
 - double getBalance ()
 - boolean isAddressValid(address)
 - send(destinationAddress)

@woolly_sammoth will work on NuStringEncrypt, a stand alone easy-to-use encryption tool written in Java that takes a list of unencrypted strings and encrypts them. It should also expose the following methods via an Interface:

 - String[] encrypt(String[] inputStrings, String passphrase)
 - String[] decrypt(String[] encryptedStrings, String passphrase)
 - String decrypt(String encryptedString, String passphrase) 

After testing this version will be released to custodians.


This version will contain the initial Integration of with NuBot : i.e, the bot will be coupled with hotwallets.

-feature 1: It will read from JSON configuration file that specifies an array of clients. Sensitive data have to be encrypted before being passed to the bot .

      "coupled-wallets": [
          "coincode": "",
          "ip": "",
          "port": "",
          "rpcuser" : "",
          "rpcpassword" : "",
          "walletPassphrase" : "",
          "coincode": "",
          "ip": "",
          "port": "",
          "rpcuser" : "",
          "rpcpassword" : "",
          "walletPassphrase" : "",
  • feature 2: on startup the user will be prompted for one encryption password that allows decryption of obfuscated configuration parameters.
  • feature 3: apikeys will be also accepted in an encrypted format.


  • if a certain config parameter is set to true, activate semi-automated management of tier 3 liquidity : implement the logic that allows NuBot to request deposits from the coupled hotwallets. Custodian needs to withdraw funds from exchange to hotwallet when required (from tier 2 to tier 3).
  • this release will also include an User Interface for generating configuration JSON files.

That’s all. If Jordan believes that the proposed changes makes sense, below is a revisited overall read

Resulted roadmap updated :

  • 0.1.5 :white_check_mark: :

  • Simple implementation that allows multiple custodians to operate on the same non-USD market ;

  • Basic tier 2 implementation .

  • 0.2.1 :soon: :

  • First implementation of (tier2) liquidity distribution model [@desrever] ;

  • NuRPCCoinClient implementation [@benjyz];

  • NuStringEncrypt implementation [@woolly_sammoth] ;

  • init porting to Gradle ;

  • 0.2.2 :

  • Integration of NuRPCCoinClient and NuBot ;

  • Integration of NuStringEncrypt and NuBot;

  • API keys protection system ;

  • 0.2.3 :

  • Automated management of tier3 liquidity ;

  • UI to generate configuration parameters ;

  • complete migration to gradle ;

  • 0.3.1 :

  • Price-feed streaming service implementation

  • 0.3.2 :

  • Consume price-feeds via web-sockets (instant shift, synchronised)

  • 0.3.3 :

  • Parametric liquidity distribution models (configurable)

  • Market-aware tier2>tier1 movements

  • 0.4.1 :

  • Market-aware liquidity distribution models ( adaptive )

  • 0.4.2 :

  • 50% code coverage

  • 0.4.4 :

  • NuBot toolkit release ( trade history, balance history, price-peg execution bot, encrypt/decrypt tool, config generator )

  • 0.5.3 :

  • 60% code coverage

  • 0.6.1 :

  • Futures markets integration

  • 0.7.1 :

  • Liquidity balancing across markets

  • 0.7.2 :

  • 80% code coverage

  • 0.8.1 :

  • Real-time reports

  • 0.8.2 :

  • API functional tests

  • 0.9.1 :

  • Redundancy bots

  • 0.9.2 :

  • Continuous integration

  • 0.9.3 :

  • String externalisation and translations models

  • 1.0.0 :

  • Bot manager GUI


It does make more sense to my mind to actually utilise the tier 2 funds while they are on the exchange. They are subject to the same exchange default risk whether on order or off. the only downside I can see is that it gives a visual clue as to how much liquidity is held on the exchange by the custodian. If the amount on order at any one time (not just tier 1) were a changeable parameter in NuBot then that would mitigate this (small) risk.
Beside that one small consideration, a very nicely presented roadmap. I look forward to implementing these changes.

I agree with this, I didn’t add to the original post to avoid extra confusion. But now that you mentioned, I take the chance to expose the max-tier2-volume as a config parameter.

In my understanding it means the bot will take money from Tier2 to input into Tier1 at the best price position 1) or it will take the liquidity available at the second best price position in the incremental buy/sell walls models and move it at the best price position 2)
If this interpretation is correct, based on which criteria does Nu choose 1) over 2) for example?

Very good question, good that you guys actually read these long proposals and discuss ! To avoid biasing with my opinion, I ask you, what would you choose : 1), 2) or none of the above :slight_smile: And why

I don’t understand the difference in both options. As far as I understand the Tier 2 liquidity will be used to build the incremental buy and sell walls. The peg is only obtained through the Tier 1 walls, so this is the only place where we demand a specific behavior of the custodian. How the custodian manages the Tier 2 liquidity (off order book, or incremental walls) is not our business, as long as the Tier 1 walls are sufficiently large.

What I would love to see is the possibility as NuBot operator without custodial grant to run a NuBot that solely provides liquidity at price position 2 or larger.

To a certain degree this is true, and for this reason tier2 is designed to be fully configurable with input parameters vs being imposed.

Non-custodian can obtain that effect by setting a wide® spread.

So I can do this right now? I already thought about simply faking the txfee because I couldn’t find a specific parameter for the spread. I haven’t done it yet because I don’t want the NuBots to start fighting for some reason. But if you give green light, then I will try that later.

1 Like

greenlight, PM me for configuration parameters and tips .

1 Like

Working like a charm - easy to configure, understandable error messages, only some more verbosity levels would be nice to filter the output. I can only encourage everyone who is interested to give it a try (with small amount of funds). I can also help with the json files so you don’t need to bug @desrever with that, just send me a PM and we’ll get this started.


The ideal state of NuBits will be when elected LPCs solely support NBT/USD trading pairs to create a hard $1.00 US anchor, and all other speculators run their own NuBot implementations on NBT/BTC with whatever spread they desire. I think it’s great to see @creon working on a partial implementation of this concept with wider spreads around the elected LPCs. When those elected LPCs are moved permanently to NBT/USD pairs, creon will have an operational advantage over newcomers.


After rethinking about it, i agree that it does not make so much difference.
Tier2-buy/sell walls are being put in the order book whereas pure Tier2 liquidity is not being put in the order book while being deposited in the exchange. So there is no advantage in case of an exchange’s defaults.
Perhaps, it is simpler to replenish the tier1-buy/sell walls by first shifting some of the liquidity of tier2-buy/sell walls and then completing the missing liquidity by taking some money from pure Tier2, from a process perspective ?