A fixed cost pool attempts to fix the minute by minute cost in NBT of liquidity provision, despite the actual liquidity provided. By paying full compensation to any LP willing to provide even the thinnest wall, an FC-ALP incentivizes providers to maintain continual and balanced liquidity provision in order to maximize their personal profit. It also causes direct competition between providers by forcing them to share the reward proportionally to the liquidity they provide. Finally, FC-ALP makes accounting and pool parameter selection much easier by greatly decreasing rollover funds and removing all reference to a liquidity target.
=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=
Operator: @Nagalim Type: Fixed Cost ALP Length: 30 days Exchange: Bter.com Pair: NBT/BTC Spread After Fees: 1% Tolerance: 1% (0.01) Bid Cost: 7.5 NBT/day Ask Cost: 7.5 NBT/day Operator Fee: 100 NBT Total Grant: 550 NBT Term 5 Requested Funds: 450 NBT
If @Nagalim decides at any time that the use of the fixed cost software may compromise the NuPond brand, the pool may switch over to a fixed reward pool at dual side 3,000 NBT targets with 0.25%/day reward rates.
=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=
Verify. Use everything between and including the <motionhash></motionhash> tags.
This is so beta it’s basically alpha. There are issues with how it’s implemented that remind me how hopelessly bad I am at professional coding; however testing has been promising and I think successful LP will show other pools how useful the concept is.
The compensation per minute will be:
7.5NBT/day / 1440 min/day = 0.0052083 NBT/min
The pool pays out this amount of NBT per minute - but to all liquidity providers (if there’s at least one, I think)!
If there’s only one liquidity provider (LP) with 1 NBT on buy and sell side, this LP will earn 7.5 NBT/day for each side.
If there are more LPs they share the 7.5NBT/day in relation to the amount of funds they use for providing liquidity.
I think that’s what you meant by saying
It is a reasonable expectation that people will fill the buy and sell side to a level with that they feel sufficiently compensated.
The competition is inherent. Of you provide 1 nbt and start absorbing 7500%/day rates, it will show up on the liquidity feeds on your raw.nupool stuff and attract LPs. As others start outing in nbt, your 1 nbt is no longer earning you a huge portion of the daily reward, so you put more liquidity in the pool. The pool quickly reaches the solution where either:
A) All the liquidity you can afford is in the pool
Or B) You have set the ‘interest’ in the config file and your liquidity gets taken down when there are so many participants that you’re barely getting compensated.
Here’s the kicker. The only changes I made basically come down to a single line in server.py where I divide the rate by the liquidity provided (the pool still pays 0 nbt if there are no participants on a side). That means my config file is fully intact. If I am correct, you should see a really small number (proportional to 7.5) for rate and a really large number for target (10 million). I was hoping to have the rate be 7.5, but I had some bugs. I’m not completely sure I understand how the liquidity submission process works, but I’m hoping you can derive the current % rate of payout and report that, as well as the constant ppm paid in total to all LPs.
That depends which value you’re giving. Per month, day, minute, second… Anyhow, it should be easy to calculate through altering this
7.5NBT/day / 1440 min/day = 0.0052083 NBT/min
calculation .
As for the current % rate:
I’m not 100% sure how this is calculated… I would need to count all orders together and get all NBT currently on the pool at the moment and just divide the ppm?
sure, that would work. The rate is the same for all users in any given minute. An individual user’s rate is their ppm (times 1440) divided by the liquidity that has been credited to them in that minute. Because of the math behind fixed cost:
ppm_individual * 1440 / liquidity_individual = Sum(ppm) * 1440 / Sum(liquidity) = rate in this minute
This is also true for fixed reward, but in a somewhat more trivial sense. Honestly, @willy, I’m pretty sure you won’t need to change anything on your end except the fixed maximum rate which will be many orders of magnitude off and the wrong units (change from %/day to NBT/day). The stuff that really changes every minute should basically remain the same.
Because I don’t need the money yet and I want to separate the fixed cost vote from the home pool grant and the possible hitbtc grant. This motion will increase the requested funds in my home pool grant by 450 NBT and will cause the network to owe me 100 NBT. My home pool grant will continue the trend of CNY/NBT 5,000 NBT on each side at 0.2% rate with a 50 NBT operator fee, which I fully expect to pass. The purpose of the home pool grant as opposed to controversial motions is to provide a set of buffer parameters whereby consensus can be reached between operators and shareholders for the actual grant proposal so the system better resists stalemate.
The setup comes from here: [Draft] Periodic 90 Day ALP Grant Competition
but the approach is more general than that for this particular motion. I am specifically testing the shareholder support on Fixed Cost Pools in Term 5 of Nupond for the BTC/NBT pair.
@huafei The current server is 45.55.55.197:3333 and I am working on putting it on NuPond.net. Once the motion passes I will smoothly transition all LPs into the fixed cost model with a simple python script restart and manual distribution. Upon achieving shareholder support, nupond adoption will not require any changes to the client by the LPs.
