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

[mhps]

This post is to extend disucssions on “Fixed per-minute total interest payout” for liquidity pools here

[Passed] Motion to begin NSR buyback immediately

@masterOfDisaster
because the buy side liquidity from ALP pools can evaporate in seconds,

Nu could encourage liquidity provision when liquidity is low by setting the interest rate higher when liquidity is low. For example it seems easy to implement for ALP – just fix the total payout every minute so that less total liquidity gets to earn more interest for the remaining liquidity providers. This fixed perminut pay out also allows removal of fixed target, simplifying operation, and feels fairer to the liquidity exceeding the target (they can earn interest as everyone else)

@Nagalim pointed out that

[Passed] Motion to begin NSR buyback immediately

but it also necessarily increases amount of money paid out per month (no more rollover dollars) assuming fixed pool rates (i.e. rates would need to go down).

I think the rollover money is a result of unfullfilled target. If a fixed per-minute interest is implemented, every pool will have to pay out a fixed amount of interest every month. Pools with less volume will get a proportional greater boost (they pay higher interest) compared with a pool with more volume, if they are granted with the same interest funding by the Nu shareholders every month. This has an equalizing effect on trade volume to pools receiving the same amount of funding.

Shareholders will directly control the volume of a pool by controling the amount of interest grant.

Quality of the exchange where a pool operates will have an impact on pool popularity. Less quality (e.g. safety, overall liquidity, API problems) pool will have to offer higher interest. If fixed per-minute payout scheme is implemented, Nu shareholders will observe who is the best quality pool that has the lowest interest for the same interest grant. The shareholders might choose to grant more to the pool on better exchanges.

To summarize, fixed per-minute total interest payout scheme

• gives shareholders directly control of the Nubits pegging liquidity,
  both globally and individually over every pool.
• It incentivises liquidity provision when liquidity is thin, hence increases peg security.
• Artificial liquidity targets currrently used, which either are unreached or reached but shut extra liquidity out, will be removed.

Please offer what you think.

[Nagalim]

Nu shareholders will observe who is the best quality pool that has the lowest interest for the same interest grant. The shareholders might choose to grant more to the pool on better exchanges.

You are assuming that we will go through a period where all pools have the same reward. Rather, I think we will immediately state some amounts. Here would be my ideal distribution, assuming 10 kNBT/month:

NuPool gets 3000
NuPond gets 1500
Liquidbits gets 1500
NuRiver gets 1000
NuLagoon is restricted to 3000

[mhps]

I think we will immediately state some amounts.

Right even the monthly total interest is different, higher quality exchanges/pools will likely still attract more liquidity providers.

I think the evetual distribution should be allowed to adjust according to who offers the most liquidity for the money, and to exchange risk mitigation strategy.

[masterOfDisaster]

The idea is as simple as it is ingenious!
It will require some work on the code of the ALP server part, but I hope that this is not too much effort to spread the compensation that is paid per minute equally to all participating liquidity providers (but still in relation to the provided liquidity!).

In the result it provides easier management of the pool and a big incentive for liquidity providers to keep their funds in the walls (even in turbulent times - or especially in turbulent times when others pull their money from the walls).

Here would be my ideal distribution, assuming 10 kNBT/month:
NuPool gets 3000
NuPond gets 1500
Liquidbits gets1500
NuRiver gets 1000
NuLagoon is restricted to 3000

I think the evetual distribution should be allowed to adjust according to who offers the most liquidity for the money, and to exchange risk mitigation strategy.

This is just what happens on grant basis already - NSR holders decide how much money to put in which pool. Nu should adhere to that.

The incentive for liquidity providing is impressive.

Based on the numbers above:
if there were on NuPool, providing liquidity at bot Bittrex and Poloniex and were the last one to provide liquidity, I did get 10 NBT per day or 0.0069 NBT per minute - no matter how much money I have in the wall!
I’d never even think about pulling my money from the ALP and instead hope others did!

I see an incentive to provide liquidity in as many ALP operations as possible for exactly that reason.

[mhps]

This is just what happens on grant basis already - NSR holders decide how much money to put in which pool.

Except currently shareholders have no simple objective indicators to evaluate who is doing the best job. There are several non-orthognal (i.e. correlated) parameters involved: interest rate, actual volume, and target. This makes things complicated to analyse.

[masterOfDisaster]

Right.

But there’s another soft benefit of the proposed change.
Afterwards the ALP operation is the perfect PoS analogy to PoW mining (pools):

• at PoW people fight for (mostly constant) block rewards and are competing with hardware
• at ALP people fight for constant per minute rewards and are competing with money

[mhps]

Afterwards the ALP operation is the perfect PoS analogy to PoW mining (pools):

• at ALP people fight for constant per minute rewards and are competing with money

Interesting notion. The analogy isn;t perfect however because for a POS system difficulty is global. Every one on the network competes for the same reward. For ALP with fixed interest total, the fixed part is to the pool. This could open 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.

One way to discourage such behavior is to reduce reward for reduced liquidity (increase “difficulty”). If the total interest paid to the pool every month is inveresely proportional to how much liquidity the pool provided per interest dollar last month, then the pool will have an incentive to remove/reduce the said gaming behavior. But this doesn’t totally eliminate the gaming incentive.

Also the shareholder need to know liquidity contribution form a pool with reliable accounting.

[Nagalim]

I feel like attackers of that nature will be mitigated by shareholder involvement in picking and regulating their operators. If you mess with your own pool, you risk losing the monthly pool operator fee. If the exchange messes with the operation, they risk losing Nu support. Basically, if things don’t work properly, people will complain and bring the shareholder spotlight down on the pool.

One thing to consider is that if an LP is alone on a pool in the current system they are motivated to supply up to the full target. In a fixed payout pool, there is no motivation for an individual LP to provide more than 1 NBT of liquidity if alone on a pair.

[masterOfDisaster]

The analogy isn;t perfect however because for a POS system difficulty is global. Every one on the network competes for the same reward. For ALP with fixed interest total, the fixed part is to the pool.

Of course it isn’t. Every pool provides a reward the liquidity providers (following: LP) can compete for.
But it’s more similar to PoW mining than the current model.
The current model reminds people of lame banking interest stuff ^TM etc. instead of cool competing for rewards stuff ^TM.
That would distinguish the ALPs even more from NuLagoon, which is good in exactly doing that: taking people’s money and providing an interest for it (Pool C: current annual interest (on USD value): 42.45 %).
Using NuLagoon is more continuously and LPs have lesser control over their funds.
Using ALP is more agile and gives full control over the funds (unless the exchange messes that up).
People can get interest at NuLagoon and fight for compensation at ALPs.
Just sayin’…

[…]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 bigger danger (in theory) indeed could come from pool operators. They could sabotage all others and leave only their own bot provide liquidity - no one could say for sure that this bot belongs to the operator or some affiliate.
Practically I see too much effort in starting and operating a pool, than it would be worth risking all that because of some extra NBT per month (even if it’s some more than just some ).

One way to discourage such behavior is to reduce reward for reduced liquidity (increase “difficulty”).[…]

This is indeed a way to fix that, but introduces additional complexity.
I’d like to avoid that complexity, because there is a hard way to fix this if it were ever to happen:

I feel like attackers of that nature will be mitigated by shareholder involvement in picking and regulating their operators. […]
Basically, if things don’t work properly, people will complain and bring the shareholder spotlight down on the pool.

The latter one already happens. I only say CCEDK and their API
All my logs of the BTC ALP have 6,861 lines containing “efficiency” (it’s a little bit better - but still far from perfect - for the USD ALP on CCEDK, although I have no clue why. Been to lazy to dig deep in the logs to find the difference…).
6,626 of those lines don’t contain “efficiency: 100.00”, but something else:

grep "efficiency" alp-collection/unix/liquidbits_ccedk_btc/logs/* | wc -l
6861
grep "efficiency" alp-collection/unix/liquidbits_ccedk_btc/logs/* | grep -v "efficiency: 100.00" | wc -l
6626

Now I know that this is related to CCEDK and their API from communication with @cybnate and her information (first I thought it could be my internet connection).
Even if the performance is somewhat degraded, it’s worth being LP there.
What I’m going to say is: people will have an eye on this. It’s about their money. They will watch that.

One thing to consider is that if an LP is alone on a pool in the current system they are motivated to supply up to the full target. In a fixed payout pool, there is no motivation for an individual LP to provide more than 1 NBT of liquidity if alone on a pair.

There is no motivation for the same LP to provide more NBT, but…
…economy is our friend!
Say, there’s only 1 NBT provided. Another LP only needs to put in another 1 NBT to receive half of the total compensation per minute.
Where’s this pool? I want to be LP immediately there! I’d even put in 9 NBT to receive 90% of the compensation, ah no, 99 NBT to receive 99% of the compensation!
See?

[mhps]

In a fixed payout pool, there is no motivation for an individual LP to provide more than 1 NBT of liquidity if alone on a pair.

I would argue that this situation creates powerful incentive for others to become LP on this pool. If for example @willy’s pool page lists current interest rate, human greed will ensure that the situation above will either not happen or disappear in a flash.

[willy]

@willy’s pool page lists current interest rate,

I was pinged. Here I am.

I’m not sure I understand that sentence 100%… because it does list the current interest rate already?

[mhps]

Ah not yet. This thread brings up a possible change to nubits pool operations such that interest paid to unit liquidity is adjusted constantly and needs to be widely known. A pool page like the one you maintain will be an important part so you are welcome to follow this thread.

[masterOfDisaster]

Except currently shareholders have no simple objective indicators to evaluate who is doing the best job. There are several non-orthognal (i.e. correlated) parameters involved: interest rate, actual volume, and target. This makes things complicated to analyse.

With a fixed rate shareholders could read how much compensation LPs require for doing their job on a specific ALP/exchange.
They could read it from the utilization of the ALP.

Example: if an ALP now offers 10% per month up to 1000 NBT (target), this would be translated in a fixed payout of 100 NBT per month at this ALP.
If you divide the payout per month by the average money from LPs at this ALP, you have the rate that LPs want to have for providing liquidity there.

[cryptog]

It incentivises liquidity provision when liquidity is thin

This is nice.

[mhps]

Example: if an ALP now offers 10% per month up to 1000 NBT (target), this would be translated in a fixed payout of 100 NBT per month at this ALP.

There are two related problems with current scheme that might not be obvious -

The pool could fail to reach the stated target and it would be hard to tell whether increasing the interest or decreasing the target is the best solution.

If the pool reaches the target often some liquidity, being judged as exceeding the target although they are liquidity just as any other, doesn’t get paid. The pool didn;t reach its real potential and some LPs are unhappy.

[Nagalim]

If the pool reaches the target often some liquidity, being judged as exceeding the target although they are liquidity just as any other, doesn’t get paid. The pool didn;t reach its real potential and some LPs are unhappy.

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.

Anyway, I’m still for it. I took a look at the code and have a strategy for making some cheap and stupid changes that I’m hoping won’t break stuff such that I can adjust the MaxRate parameter to equal a specified number (0.02 NBT/minute for example) divided by the currently supplied liquidity (labeled ‘mass’ in the code, I think). The fix the target equal to mass and see what happens. I’ll try to set up a server with piss poor security and no payouts just to test it out. I don’t think I need to even download Bud or the blockchain.

[masterOfDisaster]

I’ll try to set up a server with piss poor security and no payouts just to test it out. I don’t think I need to even download Bud or the blockchain.

Just tell me the details when it’s ready in case you need a tester!

[Nagalim]

45.55.55.197:3333
CNY/NBT on bter

It should be crediting based on 2 NBT/day. I’ve got 9.83 NBT ask side up. As far as I understand, it should credit sell and buy side separately. The target is 100,000 NBT because I didn’t want to mess with it too much. When target is reached, the bot stops crediting LP’s. Still, this should be good enough to play around some if y’all want. The reason for that bug is just because I don’t understand floats in python (I think). Any time I tried to multiply maxrate by something less than 1 it messed up, so I just usued a super small starting rate and multiplied by 100,000/mass. So if mass>100,000 (i.e. $100,000 targets) the bot bugs out and stops crediting people.

Oh and tolerance is super huge, so don’t worry about that. I did end up downloading nud, by the way, just to create nu.conf so it doesn’t error out.

[Nagalim]

I gotta say, it’s pretty sweet to be the original LP on a pool. I’m making over 8 cents an hour on less than $10. Well, hypothetically anyway.

[masterOfDisaster]

45.55.55.197:3333

Be glad about your head start. Will be there quite soon^TM