Current Liquidity

$170,000 total volume. $150,000 at Poloniex. — CMC

Poloniex sell side at zero again.

@masterOfDisaster: How is gateway looking? Can we see that somehow?

"BETwD8nSjtj9ADSvej2na34xmsMYwPRymv" : {
"buy" : 14773.81,
"sell" : 19415.4794

And 3k NBT showing at ALix now. Aaaand … it’s gone!

How long does it take for the bot to … it’s back!

Gone again. Should we take some more proactive action since there appears to be quite some demand?


I think so.

Price moves of BTCUSD cause a shift of the NuBot orders.
It takes some time to bring them uo (NBT sell order first, NBT buy order after that).
You can’t ease NuBot’s behaviour without increasing the hedging risk. As soon as the price moves, the orders need to be shifted.

You can have a look at the liquidity status of the gateway exactly like you did.
The (funding of the) gateway is something we need to discuss later when I’m not typing on my mobile phone.
You might already be able to guess why…

1 Like

Once again BTC was resurrected from the dead :stuck_out_tongue:
situation in Polo is reversed!
we need buy wall now.

1 Like

Sometimes we should consider waiting for people to go to NuLagoon.

According to ALiX everything’s under control.
I’d like to revert that statement.
The buy side gateway requires a deposit. The buy side runs dry.

Buy side depleted (I don’t consider 14 USD value a wall):

I’m trying something desperate until the FLOT can continue signing the tx

Update - current status:
A tiny buffer is available

modPuddle was taken down to operate the sell side gateway there (just in case that side runs dry because of another crash).
Buy side gateway running, although there’s currently only NBT on the associated account.
But 4 of 5 required signatures of the 5-of-8 multisig BTC address have been done.

Broadcast liquidity information:

Sun Jan 17 01:59:43 UTC 2016
status of sell side gateway:
nud getliquidityinfo B | grep BETwD8nSjtj9ADSvej2na34xmsMYwPRymv -A 2
        "BETwD8nSjtj9ADSvej2na34xmsMYwPRymv" : {
            "buy" : 2.36,
            "sell" : 2108.0968
status of buy side gateway:
nud getliquidityinfo B | grep BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP -A 2
        "BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP" : {
            "buy" : 0.01,
            "sell" : 2.0902

I’m going to have a break now.

Break - as if!
The buy side is empty according to ALix:

But I have one trick left.
I had the sell side gateway and buy side gateway running in “sell side gateway mode” with a low offset (0.004) to just compensate the fee and have some buffer for fluctuating BTC rates.
I could drain a bit over 2 grand in BTC on the sell side gateway, which are now in orders sized 1,000 USD on the book with a quite big offset:

The same was possible with the buy side gateway (a bit over 2,000 USD in BTC).
The BTC on the sell side gateway won’t keep the peg super exact, but buy some time until the FLOT BTC deposit arrived.

The NBT exit gateway now runs at an offset of 0.007 (buy side, of course) and considering the current BTC fluctuation, the funds will soon be available through automatic price shifts of NuBot.
BTC buy orders will be sized 3,000 USD.
Currently a bit over 2,000 are on order on the buy side gateway (all available funds):

03:24:15.973 [Strategy Secondary Task] WARN  - **BUY** orders re-initialized on  **poloniex** :  1/1 placed successfully
total amount placed : 2095.7568852257
Tier1 order size : 2095.7568852257
Tier2 cumulative order size : 0.0 (0 orders)
03:24:16.185 [sendLiquidity] WARN  - Liquidity is not being sent : orders are not yet initialized [c.n.n.t.SubmitLiquidityinfoTask:147]

Now I’ll really have a break.


@masterOfDisaster is doing an amazing job. We are lucky to have you.

Clearly, it’s unsustainable all the work he’s doing to protect the peg. I’m considering applying to operate a gateway myself as well, but it’s daunting to handle the amounts of funds. I am also not confident in the accounting needed, but I guess practice with small amounts should resolve that.

Are additional gateways desired? The risk of funds on exchange would be equal to funding the existing gateways more, just adding the risk of myself. But assuming I don’t run with the funds, we would spread the other risks between gateway operators and supposedly improve availability (though it would seem mOD is available all the time). Relieving @masterOfDisaster of work is increasingly important.

@masterOfDisaster: Is the matter of availability mostly that you currently have to manually switch which gateway is running, and move funds between them? Can we automate this? Would another RPi help? I believe Nu would (or should) pay for one in that case.

I think the gateways seem elegant, but perhaps I’m lacking awareness of superior alternatives. Are the suggested T3 custodians intended to send funds to say a gateway in need, or will that remain FLOT’s responsibility?

Which are the best ways people can help to improve liquidity flow? Do we need ideas, or do we have the ideas and need execution?


With the passing of the T3 custodian role some relieve should be in sight. I’m also considering running gateways, either as a backup or to support T3 custodians. Will need to do more testing and understanding what is required to operate this properly.

I’m also considering joining the T3 crowd, but it’s really because I am still dissatisfied with the deals offered by NuLagoon Tube. The best way to justify my ideals is to set up competing services.

But I also prefer to take a different approach than either NuLagoon tube and masterOfDisaster and make it sustainable yet as low-cost as possible. Cooperation is possible with multi-sig, so if somebody is comfortable running nud and some scripts 24/7 for a very little bit of pocket money please let me know. The primary justification of this though, is to rehearse for possible forms of liquidity operations with the birth of BCE.

I also hope FLOT members could voluntarily do more load balancing, where the NSR group could help the NBT group - monitoring walls and creating transactions etc.

1 Like

I’m all ears and happy to run another instance of nud and some scripts on one of my servers or even setup a separate instance eventually. Getting it sustainable and as low-cost as possible should be priority one for Shareholders.

An update might be appropriate:
Liquidity seems to be under control for the moment.

The BTC deposit at the NBT exit gateway arrived.
Once more the FLOT was able to execute a transaction (one that required 5 signatures!) at record speed: approximately 7 hours from identifying the need until broadcasting the transaction.

The situation was more dire than I experienced before. I (ab)used dozens of BTC on the sell side gateway (that were waiting for withdrawal) to support the peg (violating the terms of gateway operation) to buy the FLOT some time.
Some details about that can be found in the editing timeline of Current Liquidity


I second that.

1 Like

The buy side gateway accumulated 11,900 NBT as proceeds from sold BTC.
24 BTC are left on the exchange account to be traded (currently valued at $9,100).

I’m switching the buy side gateway to a dual side NuBot. <- This is a link - just in case you might not notice.

This way the 11,900 NBT are available if demand for NBT increases, while the 24 BTC can be traded if demand for NBT declines.
This creates a buffer in addition to ALP of roughly $10,000 each side.

I adjusted the offset to 0.009 to create a line of defense beyond the orders of the ALP.
Including the exchange fee and the allowed price move before a wall-shift gets triggered (0.1%), this should keep orders in the corridor of BTCUSD +/- 1%.

Funds on the dual side NuBot will only get traded in case no offers with smaller spread are available (funds, drained, ALP/NuBot shifting walls, etc.).

@woolly_sammoth, @willy can you please confirm that I’m outside the offsets for which NuPool compensates LPs?

translates to offset values of 0.005 in NuBot (if run with "wallchangeThreshold": 0.1,), right?

Btw. what price feed do you use? There could be deviations between feeds as well; I’m using the one from

It would be good to know the parameters of NuLagoon’s NuBot to not interfer with that (=to have a higher spread) - they have one at Poloniex, don’t they?
This is what made me think there’s a NuLagoon NuBot.
@henry, can you please enlighten me?

The sell side gateway is currently well-funded with NBT, but has only few BTC.
I operate it with an offset of 0.009 and a "wallchangeThreshold": 0.15, (price tolerance before walls get shifted 0.15%) to have orders on the sell side that are in between ALP and the dual side gateway and stay longer than the dual side gateway, because of the increased price tolerance.
I hope to be able to grab some BTC this way until NBT and BTC are balanced in the exchange account.

Then I will run the (then former) sell side gateway in dual side mode (because it has more funds than the (former buy side gateway) and provides more buffer.
I’ll stop the buy side gateway (which is currently in dual side mode)
I’ll start withdrawing the funds from the buy side gateway to FLOT addresses thereafter.

Current status of the former buy side gateway, now dual side NuBot:

status of former buy side gateway:
nud getliquidityinfo B | grep BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP -A 2
        "BFGMPykfKxXZ1otrCZcsbnTwJjKHPP9dsP" : {
            "buy" : 9353.44,
            "sell" : 11919.2544

Pybot uses a failover method. Bitfinex -> Coinbase -> Bitstamp


1 Like

I’ve tuned most of the offsets to be maximums in the recent update:
^the offset there is 0.0075 (which is indeed 1.1% SAF)

1 Like

NuBot has backup feeds as well. I’ll adjust them to the same primary and backup settings

So I need to increase the NuBot offsets to be above 0.0075, if I want to offer “more expensive orders” than the orders for which ALP participants get compensated, right?

yuuup. If you’re really a peg break scenario, you should charge like 1.2% offset (2% SAF)


that’s what I’m trying to prevent! :wink:

This really reverts back to KTM and jmiller times when Nu money is put on exchanges – both in operational nature and in magnitude of fund amount. I would also be very worried to upgrade/tinker with the bot software because a bug or an operator’s error could cause a lot of damage.


Very true, the amounts are signifcantly lower though, the risks are the same. I don’t like it either, but our only T3 custodian only starts next week and no other options are even on the horizon and the peg still needs to be maintained. Any ideas reducing the occurrences of the use of the gateways are welcome and I would definitely vote for them. Bring them on!