Thank you for the last few posts and the offers made. I’m happy to say that a donor was found and the pool has been funded for long enough for the proposal to pass (I hope). Funds from the passing of the proposal will be used to pay back the funds received as soo as it passes. I will start work on the next proposal tomorrow and allow for some debate around the changes that are happening around liquidity provision, which th plenty of time left for a round of voting.
5 Likes
can you please comment?
thanks 
i have set offset = 0.005 but sometime my order is at the top of the order list and other times are far away!
i guess the far away ones are not receiving any reward!
edit: i am trying to find a way for synchronization between NuPool’s and user nubots’ rewarding boundaries. Now i understand why sometimes i saw zero rewards in pybot also!
Sorry for the delay. The order of the feeds mirrors the default order found in NuBot
If the price streamer were up this would be less of an issue but worth knowing the order for occasions when it isn’t providing the price.
It’s worth mentioning that I haven’t seen a price feed other than bitfinex used although I’m not watching the logs 24/7. Perhaps updating the price output of Eu.nupool.net/status to include the price source would be helpful?
1 Like
What is preventing this?
I don’t see the data feeders vote for it!
And in orders books i see some good liquidity in a tight spread, i guess it is from NuPool users 
That’s not correct. At least one is for days:
Cybnate supports it as well:
Check the other data feed providers yourself 
1 Like
Well, something is off! 
BRsLYtJhPhz7QdkKK54HkoizUrNk64wFwf 2 votes 12 blocks ago 2,720 NBT
BRsLYtJhPhz7QdkKK54HkoizUrNk64wFwf 39 votes 1 block ago 1,280 NBT
i saw the first line which is very very wrong. Someone is voting with wrong NBT amount!
edit: @woolly_sammoth, what is missing from Nubot ALPv2 in order to be “perfect”, is what was in pybot’s functionality, the ability for the user to see what was his/her exact reward every single minute
This amount is from edit version 3 of this OP (from May 16th).
The NSRholder who configured that vote forgot to update it or isn’t aware that an update is required.
Registering a data feed can help here - if the data feed is up-to-date.
And frequency voting wouldn’t be bad either, although I wonder, how misconfigured votes can lead to a trail of misconfigured votes for some time.
@Nagalim can you give me a private lesson, please?
@masterOfDisaster Is there any setting can avoid the nubot eat the other side’s order that pay 0.25% fee?
Sure: a sufficiently high spread.
But we all want a tiny little snippy teenie-weeny bittie spread, don’t we?
Oh, just a second: I for one am in favour of a reasonable spread that offers a good quality at acceptable costs.
the Pybot can avoid to eat other side’s order with a price check, nubot cann’t do this.
a tiny spread need a stable pricefeed avoid different price between main feed and backup feed.
a question about voting:
why SDD is over 50% so quickly in all proposals?
Has something changed in voting mechanism?
Has any meaning now?
A stable price feed was developed (the price streamer) which both NuBots and ALPv2 can hook into. That has been unavailable for the duration of the current NuPool operation. As far as I know it just needs a restart but I don;t have access to do so. I’m hoping that @desrever will see my requests to do so soon and restart it but I know he’s been very busy with other projects.
The MultiCustodian setting in NuBot was designed for this exact problem. NuBots synchronise themselves using NTP and move orders during a small window each minute (if a move is necessary). That should prevent wall clashes but the setting does impose a minimum spread
INFO - Forcing a 0.01$ minimum spread to protect from collisions
That may need revisiting if this setting is to be used with whatever happens with spread discussions.
@masterOfDisaster of disater: you asked in another thread about the ‘WallShiftThreshold’ parameter, I’m going to answer here I’m afraid. That affects the point at which NuBot decides a wall move is necessary. For multiple NuBots on a pair, the Threshold should be the same otherwise Wall shifts will move into other bots walls and we end up trading with ourselves. All bots on a pair should move at the same time to the same price. We should be using the price streamer as intended and will do so once it is back and working. Faling that we should all be using the degfault price feeds as coded into NuBot and ALPv2 to ensure the price is valid.
I assume some old shares being used to vote.
Apologizes for the huge delay.
Voted.
But to me the total target of 6k NBT is too small.
I d like to see a much higher target for next proposal.
The target was lowered in response to the lower cost. Liquidity providers get a smaller maximum reward but it is easier to reach the maximum reward. Seems to balance out and make providing liquidity still attractive
1 Like
The target is a minimum not a maximum.
I disagree. And for a lot of reasons. Let’s start with the big one: centralization. As you can see, the price streamer requires a ‘restart’ from a central body. Almost no matter what, in order to keep everyone on the same price at the same time there has to be centralization, unless we make an entire blockchain just for nubot. This is woefully less robust than what we have now, people using their own derived price feeds.
My ideal LP is one where people design their bots themselves to take advantage of the market and slightly move their orders around in the allowed spread band to either reduce or increase their exposure to market orders.
Furthermore, if everyone moves their orders all at once it looks a lot like manipulation. Sure, if they go and read all the threads in Nu and keep up on the nubot development, maybe they’ll know about price streamers and a bunch of other complex concepts, but likely not. Image on the orderbook is very important and the image of a single wall moving at once is one of centralization. And funny enough, that’s because it is (see first point).
If i add in a line in my bot to wait 1 second before placing my order on top of everyone else’s order I can almost guarentee that I will never participate in a trade unless the entire liquidity is eaten. In fact, this would be very profitable because i would likely be one of the few remaining on the weak side and get paid the most.
I very much prefer the spread band model to the individual spread model. Note that so far every operation but the Tube has been using the spread band model without really talking about it. That’s what all our deviation conversations were about.
The best way to avoid collisions is to set an offset that gives a reasonable minimum spread when you take into account wallshiftthreshold and similar parameters and factors.
I showed that these fluctuations die out reasonably fast if the active shareholder stops voting incorrectly. More importantly, such a misconfigured vote will not pass unless ~50% of active voters vote for it, in which case if the majority of active shareholders are voting for it how can you tell it’s misconfigured from a blockchain perspective? The only case where it spirals out of control is for really really high apathy percentages like 99.9%.
The “server stats” page needs to show more info.
- the current users’ liquidity for both walls in order to be able to rebalance and to achieve max payout!
- the actual ask and bid reward for each user, now it is the same for both walls.
a lot of trade fee at swing of BTC , i am out of ALP v2 