[Passed] NuPool 8 ALPv2

Debating liquidity and parameters is debating one of the most important parts of Nu.
This can never be wrong :wink:

1 Like

Liquidity providers will be able to run the NuBot software now with ALP v2, so that means they’ll all have access to NuBot’s redesigned interface/gui…

Is this the point where liquidity providing becomes so easy to do that we can advertise pools to normal people (no technical experience) to get more providers on board? Reducing the difficulty like this should lower the barrier for entry.

I’m thinking about ads on the Daily Decrypt, Reddit ads and other places, but only when it’s necessary to increase the amount of liquidity provided. Of course I understand we need to go through a testing period first before doing this. What do you think? Is it getting close to the time we should start advertising liquidity providing for Nu?

3 Likes

We don’t pay $10k/month for the Sun to do it, and on top of it we always stay on the losing end in arbitrage – by design – every time BTC pricce swings.

1 Like

I believe this should be lower e.g. around 0.7% allowing for transaction for fees effectively having a tight spread of around 0.5%. ALP should hold a tight peg, but reward relatively high for that, although with a low volume to reduce costs.

I don’t support ALPs continuing with high spreads going forward now we have a decent NuBots infrastructure available supported by FLOT which can support the peg as a second line of defence at high 1%+ spreads.

Also the volume can be lowered to reduce the cost of a tight peg.

Please elaborate?

May I?

2 Likes

There is a motion which states no alp running on poloniex can require an offset lower than 0.7%. If you dont like that, you’ll need to pass a motion nullifying that spread regulation motion. Saying you wont support a motion unless it goes directly against existing motion is a difficult place to put operators in.

Are you referring to this motion?

1 Like

As Polo is going to offer <0.15% fee for market makers the minimum spread is going to be 0.65%. Hopefully the liquidity situation is will be more transparent as more people place open orders rather than dump directly on the walls. Though I suspect some code about matching orders might go against that.

Yes, I remember that highly contentious and debated motion. See my response to it here: [Passed] Motion to regulate spread values for liquidity operations. I supported some sort of guidance but this went too far in my opinion and now appears to be unnecessarily constraining as I suggested at the time.

As I’ve shared my position in that thread I’m not going to debate this again or raise motions to nullify. Instead I will call for the minimum offset this motion allows in order to have my support, which I understand is 0.7%.

@woolly_sammoth and the NuPool team

For few weeks I have seen this error running my client, and even with the reset timer or using the Nagalim client does not fix the problem. This happens only with poloniex.

INFO: poloniex - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - xxxxx

The only way to overcome this issue is to reset the client manually, but now, possibly due to poloniex api issues, it has to be restarted every 30 mins / 1 hour on average.

I believe it is affecting also other LP as mentioned on the NuPool 7 thread.

This could be the main cause why we see very unreliable ALP behaviour as shown in the charts as @masterOfDisaster pointed out elsewhere.

Has this problem been corrected with NuPool8 ALPv2?
Will the use of NuBot be encouraged? Any detailed tutorial for begineers in the plan on how to use it specifically with our biggest pool? (NuPool)

It will be forced. Maintenance of pybot is discontinued.

I am currently drafting Nu tutorials which will go live with the beginning of this operation.

1 Like

This is indeed a problem. I noticed it a couple months ago and I was hoping my restart would fix it, but you’re right that it didnt. We will be doing basically a rolling reboot of liquidity operations as ALP v2 comes out, and the software should be a lot more robust.

1 Like

Looks reasonable to me and it is in accordance with my belief that we should reduce the liquidity provided by ALPs.[quote=“masterOfDisaster, post:15, topic:3631”]
product to USD(expressed in BTC), but to USD.
[/quote]

What is the difference?

The supported trading pair.
BTC/NBT != NBT/USD

As long as wel support BTC/NBT (which will likely go on forever - B&C Exchange will have no USD…), there will always be a more losely pegged NBT in that pair than in a NBT/USD trading pair.
But a peg to USD (NBT/USD) is what Nu promises saying “…always a Dollar…”

1 Like

I’ve amended the title of this post to explicitly put it up for voting. I had thought that voting would start naturally but I can’t find reference to this grant in the current custodian votes.

The funds for the current NuPool operation have run out. I’m going to stop the pool server and make a start on updating the Operating System and making the switch over to the ALPv2 software.
As I’m doing that I will create an Ansible playbook which will be able to automate the process. I will then make that available ot othe rpool operators so that the process of making the change to v2 can be as smooth as possible

Apologies for the slightly shambolic change-over. I am continuously sorry that Nu falls to the bottom of my priority list. That is just where I am at the moment but, sorry, again.

I feel confident that FLOT and the NuBot gateways put up by @zoro and @masterOfDisaster will be able to hold the peg while NuPool takes this break. I think the combinations of Liquidity provision available to shareholders show an increasingly healthy ecosystem within Nu. I hope that ALPv2 is able to live up to the promise and bolster the ALP portion of that.

4 Likes

Well, the problem now is in Bittrex. It has no LP support!
Oh wait! There is a passive dual pybot gateway there:


I almost forgot :slight_smile:
But it needs FLOT’s funds.
@Nagalim, can you send some T3 funds there and ask them from FLOT later?

1 Like

Firstly, id need to decide on a price. Which brings me to the next point, the T3 gateway is set up so that I can charge whatever i want based on whether i want to make the trade or not. So if I charge a 10% markup, how do i know it wont later get rejected and then we’re all in a sticky predicament.

I think FLOT should make a 1of-8 btc address with $5k btc in it for sending to gateways.

1 Like

Let’s say 3-of-8 or at least 2-of-8; trusting you and trusting every single person in FLOT with $5k is quite different. One compromised key and all will go in a puff.

What about 2 2-of-3 groups with $5k or $10k each?

That way both agility and relatively high security together with the need to achieve consensus for executing transactions could be achieved.
Alternatively one could think about singlesig FLOT addresses with smaller amounts of funds, although I think this is not the way, which Nu should go.

But a subdivision of FLOT with more agile multisig (e.g. 2-of-3), where only relatively small amounts are kept, makes sense.

1 Like