Sounds straightforward.
I will make a comprehensive update of the proposal as soon as find time. Done!
Is there any need for improvement of the draft?
Keep in mind that it’s dealing with a band-aid solution!
I don’t want to delay the start of the motion more than necessary, because there’s gray area to be covered.
ok, do it.
I am also trying Nubot in win7 64 for the first time. Nubot is a piece of art!
The only strange thing i see is with Java SE 1.8. When Nubot running (CLI with browser) , CPU (AMD 4-core) is at 100% so i used affinity:2
Why not consider a wider offset, like 0.005, or 0.007?
Right.
I now realize that the total spread of the proposal is not in the range defined by the motion to regulate the spread:
Adjusting it to 0.007 on both sides should result in a SAF of 1%, right?
yup, polo has a 0.2% fee, so 0.007 should do it.
After repeated trouble with low liquidity on buy or sell side which made me (ab)use funds (that were waiting for withdrawal), I created this draft.
The intention was to legitimate what I was already doing.
I’m exhausted, deeply tired from continuously monitoring the liquidity situation and doing my best to support the peg.
I already used the gateway as dual side NuBot, but with a time shift in between: first they converted NBT to BTC or vice versa. Then came the need to support the peg and I reversed the config.
At the moment both gateways are running, effectively creating a dual side NuBot, but with a split brain.
If a gateway would run in dual side mode all the time, there would be no need for manual intervention.
As soon as one of the gateways is close to 50/50 balance, I’m going to stop it, convert it to a dual side bot (offset: 0.007, 0.007), start it again and shut down the other gateway.
I’ll put up this draft for voting.done
NSR holders might decide whether they want to have that kind of buffer at the currently most important exchange or not.
For the time being I see no alternatives. T3 custodians and fixed cost are hopefully a game changer.
I hope that my solo can show the easing for the liquidity situation on the way through the voting.
I only see two options from here: either I’m formally allowed to have done automatically what I did manually so far, or I let it be. It feels bad if you are sure to do the right thing, but know that you aren’t allowed to.
If this motion doesn’t pass in an appropriate time, it’s clear that the NSR holders don’t agree with what I do and I’m bound to follow their decision.
I won’t use gateway proceeds, that wait to be withdrawn, to support the peg thereafter.
That I can suspect
TL;DR
How much is the value of a flawless track record of the peg?
And how supportive is the dual side NuBot on Poloniex to keep that track record flawless (at what cost)?
I fear, both are questions that can only be answered by gut feeling.
My gut feeling tells me, it’s worth it.
The peg is of paramount importance for the perception of the quality of (US-)NBT (and the products that will come!).
With a flawless track record people look at NBT and say “Wow, it worked so far, impressive!”.
With one single peg failure the tenor may shift to “It already failed once…”.
That’s the reason why I worked my ass off in the recent past - the peg must be kept!
/TL;DR
Long read
NSR holders need to feel uncomfortable having funds on an exchange.
But NSR holders should feel uncomfortable with an endangered peg as well.
The good and the bad thing is: the major trading volume and the main focus is on Poloniex:
70% - 90% NBT trading volume was on Poloniex in the recent months.
I don’t see immediate need for dual side NuBots on other exchanges. Maybe gateways, but no dual side bots.
It was for that reason I created the gateways at Poloniex: whether we like it or not (in terms of relying heavily on one exchange): Poloniex is the most important exchange for Nu.
The ALP showed that it doesn’t react fast and flexible enough to support the peg sufficiently if Bitcoin is in rollercoaster mode. Without the gateways, the peg might have been lost.
From the experience I made with the gateways, I’m inclined to suppose that a lot, or even the majority of trades on the NBT/BTC pair is done by bots.
The pace slowed significantly down once the “cheap” orders were bought.
But Nu shouldn’t rely on dealing only with pro traders, who stop their buys or sells if the wall is emptied, to ensure the peg.
A buffer of approximately $10,000 on each side would help a big deal.
If the buffer is starting to get consumed, or rather shifted to one side, the dual side bot can be funded to support the drained side just like the gateways are currently being provided with funds: deposit them and let NuBot put them on order.
To add some background info to this topic I digged in an old thread that dealt with the liquidity operation of KTm and jmiller.
I found out that
jmiller managed funds of in total 228,798 NBT:
on several exchanges and
ktm managed funds of in total 1,023,038 NBT
Of course not all of the funds were on exchange - far from it!
And several exchanges were supported by the two (not only Poloniex).
Yet a lot of money (one and a quarter million!) was in “single point of failure” situations.
While it wouldn’t have hurt much to simply lose NBT forever (given they would be lost unrecoverably - like burned), losing proceeds from NBT sales would have hurt, did hurt.
That was a lesson learned from the February exchange defaults.
Yet, that’s exactly what the dual side NuBot will create again: a single point if failure.
But for a total of a few thousand USD.
Adding this motion to my datafeed.
The longer I thought about it, the more use I saw for a dual side bot in “active standby mode” (running, but unfunded) to replace gateways.
It’s not clear to me that I will decommision the gateways on Poloniex soon.
Upon passing of this motion I will operate a former gateway in dual side mode and reveal the deposit address, that is missing to fund it dual sided (tell NBT address of the NBT exit gateway; tell the BTC address of the NBT entry gateway).
This will not activate the compensation terms of this motion!
The other gateway will be shutdown.
In that state of transition, the dual side NuBot will keep funded and provide a buffer outside the spread for which ALP participants are compensated for.
This will not guarantee a 100% perfect intact peg, but it will create a line of defense before the spread is bigger than several percent. And if one side runs dry, it can be funded just like the gateways before.
Funds will be withdrawn to FLOT addresses in steps.
As soon as no funds are left, that dual side bot will be turned to active standby mode to provide a hardware backup for the dual bot that is subject of this motion.
Makes sense – adding to my voting data feed
Thank you for your understanding and your support!
I think this band aid solution proposal makes a lot of sense.
I hope Nu will be able to totally avoid that before it starts paying fees (though I am not against in any way paying @masterOfDisaster for all work so far!)
6a2fdd44881be1d64ee5c03517525b52f607342c verified and voted.
By the way what would be the difference in terms of liquidity balancing and liquidity provision between providing funds to this dual side NuBot and increasing the incentives for liquidity provision to participating into Polo’s ALPs?
Aren’t Polo’s ALPs running a dual side bot?
ALPs should have a smaller spread and gateways put all the risk on Nu instead of the custodian. I’d be down to increase ALP provision on Poloniex too.
The ALPs are running a dual side bot, but not with Nu funds and at a smaller spread.
+1
The current compensation seems to be insufficient to attract enough liquidity at Poloniex’ ALP.
From https://nupool.net/index.php/Current_rates:
Well spotted. Exactly for that reason should the gateways only be used in emergencies.
And if a NuBot runs permanently in dual side mode with Nu funds, it can only be cheaper than sustaining ALP, if the hedging risk gets reduced by having a bigger offset than the ALP.
The same stay true whether the funds are collateralized, provided by the bot operator (MLP), or provided by Nu.
Exactly to that… I pulled my liquidity from polo and Bittrex because the compensation didn’t fit the risk faced due to the btc swings.
What rate would you prefer? Ye olde 0.3% per day / 9% per month?
With fixed cost we could find it out 
I think we’ll find that the ideal approach is CRFC that is always at target (using something like a 0.5% reward). Note that this is identical to FC, but using the threat of lowered total compensation to keep the pool at least at target. It’s similar to the idea of using a very FR reward rate and relying on the dutch auction to reduce costs.
Correct me if I’m wrong, but doesn’t that sound like round 2?
Round 1: Test the waters with fixed cost to determine the reward that LP require.
Round 2: Define a target and calculate how many NBT need to be offered to LP to reach that target (more or less).
CRFC is a neat idea to offer market aware compensation.
