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.
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
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.
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).
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.
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.
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.
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.
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 stuffTM etc. instead of cool competing for rewards stuffTM.
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’…
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 ).
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:
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:
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.
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?
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.
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.
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.
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.
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.
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.
).