Dealing with gateways in particular and liquidity provision in general

Continuing the discussion from Current Liquidity:

Allow me to reply to this post in greater length:

Thank you, but you need to keep in mind that I violated the terms of the gateways more than once.
I did it, weighing the benefits and drawbacks of it, for the greater good.
I can’t prove it single-handedly with the information I can provide myself (together with aligned ALix records it should be possible), but without the violation the peg would have lost; to some degree, for some time.
Only traders stopping to trade without orders at peg level could have prevented that.
Putting gateway proceeds, that were meant for withdrawal, on order again to support a side was the only thing I could do to buy time.
I would be happy, to not get in such situations frequently.

I do work that seems to be necessary, or at least I believe is necessary, otherwise I wouldn’t do it with such devotion.
I don’t know how long I can continue to be spot-on or can even anticipate anticipate things (that lead to the creation of the gateways).
It’s daunting. That’s why I feel so much pressure. Nu risks money. This needs to pay off for Nu.

Accounting wise it’s super simple: you receive funds from FLOT, you withdraw all proceeds to FLOT.
You need dedicated Poloniex accounts - one for the buy side gateway, one for the sell side gateway.
Create them and link them to your primary account. They inherit withdrawal limits and other profile settings from your primary account, but are otherwise separated: separate 2FA, separate API keys, etc.

I can’t to share some of the load! :wink:
Your risk assessment is almost correct.
But I come to a different conclusion regarding another operator. With multiple operators the risk is lowered not only by distributing the funds between different parties (if one operator runs with the funds, the other yet might not), but by being able to have them withdrawn faster, because of combined withdrawal limits.
Availability is increased - different operators might be available at different times and the gateway infrastructure is redundant.
Don’t bet on me being available all the time. I already know of an extended business trip in February (2 weeks), others might follow. What I did in the last weeks, can’t be done from where I’ll be.

Automated operation has some constraints.
I run them on RaPi at home. That’s mainly because I’m paranoid.
I don’t trust VPS for storing private keys. As I have applied for custodial addresses to be able to broadcast liquidity information, they need to be imported in the Nu application, which is used for broadcasting the information.
On the RaPi I run both nud and the gateway (which in addition makes backup easy). When running 2 instances of NuBot on the same RaPi2, the free RAM is balancing on a knife’s edge. I did that, but as soon as the 1 GB RAM is full, the swapping degrades the performance that I don’t consider NuBot reliable any longer.
Orders might be shifted to slow, increasing the risk hedgers pose to them.
The logs which are created by NuBot are very verbose. They eat up the capacity of my 8 GB SD card quite fast. That’s one reason to keep them idle, ready to be started within a minute.
It would be easier to let them run on a different machine, but as I imagined them for emergencies only and don’t charge any compensation, a RaPi2 seemed like the perfect match for the job.

I don’t move funds between the gateways. That would make tracking the money flows for NSR holders impossible. The FLOT addresses are known as well as the gateway addresses. All money flow is being reported transparently on blockchain.

I’m now aware that the presence of the gateways hinders creation and adoption of alternatives. That’s why I need to discontinue them or make continuing them so expensive that alternatives are prefered.
I hope for the effects T3 custodians and fixed compensation will have.
I don’t imagine T3 custodians funding gateways. I all pans out, the gateways will really only be for emergencies.

Fixed compensation makes it attractive for LPs to monitor order books, because the fewer funds on order, the higher the percentaged reward. The prospect of that reward makes them contact T3 custodians to make a deal.
And that deal requires only two parties: the LP, who is already aware of the need for a deal, and the T3 custodian who needs to reply and come to an agreement with the LP.
Even if the person making a deal is no LP and not intending to put funds on order, removing funds from the books lowers pressure on the peg as well.

If no T3 custodians replies in a timely manner, the LP can convert the funds using NuLagoon Tube.

We already have ideas how to improve the flow, which only need execution.
I haven’t found enough time to think of other improvemens, but for one:
operating not a gateway, but a dual side NuBot: [Passed] motion to permit dual side NuBot on Poloniex
I don’t consider it as improvement for the final liquidity provision of Nu (yet), but as a means to ease the way getting there without burning the FLOT or me out - or losing the peg.
A dual side NuBot can be used to bring NBT or BTC from T4 to market just like the gateways do. But a dual side NuBot has buffer capabilities a gateway doesn’t have, which I created manually by (ab)using funds.


Will it work as per this description? let’s try and test

Regarding dual side NuBot operation

For the record: I managed to track down the issue tha prevented NuBot from using a parametric order book.
"bookDisabletier2": true,
was in the configuration, because I saw no need for having T2 funds on the order book, considering the immense offset NuBot would use for that.

As a matter of fact
"bookDisabletier2": false,
is necessary to make NuBot put more than just one order on the book (if the single order size and the maximum cumulated order size allow that).

I’m not sure whether
"priceincrement": 0.002 or
"bookSellInterval": 0.002,, "bookBuyInterval": 0.002,
are responsible for the offset of the second order.

Here’s an example config for a dual side bot (taken from one of the NuBots I currently run on Poloniex) that has an offset of 0.01 for the first $2,000 order and with a price increment of 0.002 places another order at 0.012: