Fixed total payout for liquidity providers to enhance liquidity security and pool operation

[Nagalim]

Disclaimer or whatever: this pool will never pay out and any funds you lose are your problem.

20.9+9.83=30.73
2/(30.732460)*20.9=0.0009446

(I.e. it worked!)

[masterOfDisaster]

Disclaimer or whatever: this pool will never pay out and any funds you lose are your problem.

That was clear. I was just trying to make fun when I wrote

I need more money on that pool!

I think the made that clear…

20.9+9.83=30.732/(30.732460)*20.9=0.0009446

(I.e. it worked!)

Your adjustments seem to have worked. Great!
The alp-collection is up-to-date, albeit not really tested. But hey, it’s in the experimental branch
Looks like I hijack the test of the fixed rate pool to have the alp collection tested as well

Universal ALP bot collection - forked (and hopefully improved) @Nagalim edition

Update 6: I hope I caught all links in the previous posts… The repo was renamed. It’s now called “alp-collection” (formerly known as a fork of nu-pool that was called nu-pool). The most interesting branch of it is not the master (which is hopefully quite stable) but the experimental branch, that can be found here: https://github.com/Lamz0rNewb/alp-collection/tree/experimental The experimental branch contains some scripts that should make using the bots (especially if you intend to run more…

[mhps]

You guys are fast. Will test it in a day or so.

That’s not really how it works. One LP offers at a lower rate than the other (dutch auction) so it’s not really ‘liquidity just as any other’ it’s liquidity being offered willingly at a lower rate.

My zero-rate offer is constantly declined.

[Nagalim]

My zero-rate offer is constantly declined.

weird. You’re saying because the pool is full? Have you tried using like interest=0.000000001? It’s supposed to take the cheapest liquidity first.

Anyway, that’s actually one of the reasons I really like this setup: it’s actually less buggy. When a pool reaches target it does all sorts of weird stuff. By lifting the target, we are able to have a lot smoother of an experience.

The biggest concern I have is that I’m worried there’ll be a bug in the program and it’ll pay out a high rate to a bunch of people. I don’t think that should happen, but only testing will tell I guess.

Edit: Speaking of bugs, I got a seg-fault and server.py killed itself. I don’t know why, nothing in the logs or anything. I’ll figure it out at some point maybe. It may have run out of memory; Nud is such a pig.

[mhps]

The biggest concern I have is that I’m worried there’ll be a bug in the program and it’ll pay out a high rate to a bunch of people.

In the initial trial period maybe one can run the old and the new setups in paralell, letting the new one dry-run (with liquidity info feed, calc everyone’s balance, but don’t actually pay).
Then switch to the new one but make actual payment tx like every week so there will be enough time to watch how things go.

[Nagalim]

I was basically planning on doing exactly that (without the liquidity info though, I’m not feeding this a custodial address without a grant). A user could theoretically get credited on both pools if they both were shareholder funded at the same time.

But yah, I have it up and running to play around. Again, this was a super quick bandaid fixup just to see how it goes. If it looks like there’s interest, I’ll mess around with it more. I’m hoping I don’t get any more of those seg faults.

[Nagalim]

This is gonna end up being a can of worms, but I think it’s worth pointing out that this method exacerbates the ‘switching’ issue. The switching issue is such that if the peg is unbalanced it will cause providers to start trying to switch to the other side of the peg using the peg itself, causing LPs to burn up all their funds to exchange fees. It’s a phenomenon we haven’t really seen, but was talked about theoretically a while back. Creon came up with one of my favorite solutions to the problem:

Custodial Rules for the Static Peg with Fiat

Here is another idea: Set the sell side interest rate to 0.3% and the buy side interest rate to 0.05%, which however increases every validation round up to 0.75% depending on how long your funds are in buy orders. The increase should take place every validation round and reach 0.3% after about a week.

This isn’t a solution, but it discourages switching since people will have to wait more than a week until they will get a higher interest rate, which is risky, since their funds could be converted back to NBT at any time.

It however would also discourage short term buy side liquidity providers, who only want to provide liquidity for a couple of days, however, these people would in fact be wise to buy NBT and to provide them at 0.3% instantly and to sell them afterwards. So in the end it incentivizes the short term liquidity provider to provide sell side liquidity, and the long term liquidity provider to provide buy side liquidity.

We may be able to ignore this issue unless we start seeing it happen.

[mhps]

This is gonna end up being a can of worms, but I think it’s worth pointing out that this method exacerbates the ‘switching’ issue.

Why does the method exacerbates the ‘switching’ issue?

@creon’s method also discourages someone to convert NBT to USD not using the peg, e.g. selling NBT for BTC then sellling BTC for USD.

@creon really put a lot of thinking into TLLP.

[Nagalim]

Let’s make some names. Fixed Reward ALP’s are the normal kind and Fixed Cost ALP’s are this new method, OK?

So a fixed reward pool that hasn’t reached target on either side has no switching problem because the incentives on both sides of the pool are the same. Dutch auction and Fixed Cost models both have asymmetric rewards when competition on the two sides of the pool is drastically (or permanently) different. There is very little preventing an LP from selling to another LP the moment they buy nbt of the rate is different enough. That causes the LP’s to play hot potato.

You’re right that creon’s idea isn’t really a solution either. The best solution is to keep a moderate peg spread and to try to keep global buy and sell side balanced so that competition on the two sides of the peg are similar. The unseeded auction will help with that by providing buy/sell side network rebalancing on the order of days.

[mhps]

OK got it.

[masterOfDisaster]

@creon really put a lot of thinking into TLLP.

Obviously and the ALP (formerly known as TLLP) software runs remarkably well.
He was a brilliant mind, which others also recognized:

[Withdrawn] Reduce mint reward to reduce apathetic voting?

@creon was brilliant in the solutions he devised,

But be was a kind of rebel as well.
As much trouble as it might make to integrate the thoughts and work of rebels as much might this kind of thinking be required if Nu wants to become big.
We need controversial thoughts and discussion.
I believe only that way Nu can work and grow sustainably.

I’m glad that @Nagalim follows the footsteps of @creon!

[Nagalim]

So the server restarted for some stupid reason last night. The funny thing is, I reboot it this morning and now I’m the only one running on the pool. Rewarded for providing a shitty service, hell ya!

[Nagalim]

I’m pretty satisfied with the implementation at this point. It’s not an amazing piece of code, but it leaves basically the entire bot intact. The operator can even set a target at which dutch auction takes effect.

If I can get 2 testers other than me for a few days I’ll test btc/nbt for a bit and post a motion. And if you like big numbers registered on a server with no true value, boy have I got a deal for you! We’re now crediting 7.5 Imaginary NBT per day per side!

Disclaimer: Nothing is real.

[mhps]

Can you or @masterOfDisaster point to me the best pool client for switching between NuPond fixed cost, LiquitBits, and NuStream? I think I am using @masterOfDisaster’s NuPond fork but I am not sure (how do I find out? README.md doesn’t tell) I tried several version a while ago.

For fixed cost pool to work optimally when liquidity is low, it is best if LPs from other pools can jump in easily.

[Nagalim]

It’s super easy. If you’re already running on Bter’s CNY pool, just change the ‘server’ parameter at the bottom of the config file from NuPond:3333 to:

45.55.55.197:3333

[masterOfDisaster]

I can recommend to try the experimental branch of by “ALP collection”:

Lamz0rNewb/alp-collection

It contains a collection of all ALP operations I’m aware of, e.g. the windows and the unix version of this pool (including recommended settings for offfset, server settings etc.).
But this obviously just a shameless plug, because @Nagalim is right with his last statement.

ninjaedit: I just checked my ALP bot on the fixed pool and it looked strange. I restarted the bot and it still looks like:

2015/09/16-04:06:15 INFO: starting PyBot for cny on bter
2015/09/16-04:06:16 INFO: successfully deleted all orders for cny on bter
2015/09/16-04:06:16 INFO: waiting 13.45 seconds to synchronize with other trading bots for cny on bter
2015/09/16-04:06:32 INFO: successfully placed ask cny order of 20.9000 nbt at 7.23150780 on bter
2015/09/16-04:07:15 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - 
[...]

[mhps]

@mhps
[…]a gaming possibility that some liquidity providers sabotage other providers to increase his own profit, without increasing liquidity provided. This could be especially harmful if the pool operator does this.

I don’t see how LPs can sabotage other LPs - how will they get hold of required information for doing so like IP address etc. (still that’s an attack vector)?

The incentive is there so someone will try.
It’s not hard to conceive ways … for example if someone finds out where the VPS of the ALP server is and a bot running on a VPS local to the ALP server is immune from DDOS attack to the ALP server, he could run his bot on such a local VPS and use DDOS to deny all other LPs access.

One way to discourage sabotage against individual pools is connect the payout to current global buy and sell side liquidity, which every nu client has. Then the system will be more closely resemble a POS network. It could work like this -

• Nu Shareholders decide a total interest cost of pool liquidity for the next accounting period. Call it TIC.
• All fixed cost pools will split an initial payment of 50% of TIC according to some inital allocation rules.
• All fixed cost pools start to pay LPs from their own wallets that have the initial payment. Each LP will get paid according to what fraction in the global liquidity this LP has contributed in the last minute.
• Liquidity, interest, and payment information are tracked and displayed on web pages.
• Periodically a superbot will rebalance pools’ interest payment wallets and distribute the remaining TIC. This superbot is a source of centralization.But if the fraction of liquidity provided (averaged over the accounting period) has no big deviation from the initial one, then this bot may not be needed. Inter-pool clearing will happen at the next TIC allocation.

[masterOfDisaster]

The incentive is there so someone will try.

The incentive for manipulating other LPs to increase the own reward is already there, albeit with other parameters.
At the moment the incentive exists as soon as a target has been reached and no more money can be earned from providing additional liquidity.
Every LP has an incentive to sabotage all other LPs to ensure the own funds are completely available at the pool and below the target.

So this is no new problem, it only comes in a new shape.
It’s a little bit more severe with fixed payout rates, because you can get very high rewards with little money invested in the liquidity operation if you successfully sabotage all other LPs.

I think one (hopefully simple) way to mitigate that can be capping the payout rate.
I don’t know how complex that is on code level, but if you get a fixed rate only up to a maximum of x% per day/month/year, the incentive to sabotage others is reduced. It’s on the same level as it is at the moment if you choose the cap at the same rate as it is now.
I’d favor having a higher cap to attract more LPs as long as the pool is far below the expected “target”.

[Nagalim]

I can institute a cap without too much difficulty. It would essentially impose a minimum liquidity level below which it is no longer fixed cost and switches over to fixed reward.

A global implementation would be difficult and not something I’d be willing to look in to any time soon. We can keep talking about it, think out all the issues before I go hopping into the code.

@masterOfDisaster are you still having problems? You posted a line with 0% rate, but you didn’t give a full minute to register the order it placed. You should usually wait for at least the second line of statistics before making a conclusion. Also, Bter was super weird last night so let me know if you’re having issues.

[mhps]

As for capping the interest for the fixed cost pool, I think the capping level should be decided later after the pool runs for a while. The risk is limited. People are watching. Problems are reported within hours. Even someone manages to take all the interest for a day it’s just 3% of a monthly cost. The lesson would be worth it.

Global balance is indeed more complex. A less complex solution: the fixed cost pool has a cap that is liquidity-aware — it is off only if global buy side is less than, say 2000 NBT.