With nud getliquiditydetails I can pretty easily tie liquidity in the network into compensation. Because of the possibility for the reported liquidity to be invalid, we would want to breakdown the liquidity more like this:
5 nbt/month sell side
5 nbt/month buy side
5 nbt/month flexible
The flexible portion would be used such that if the network is in total 80% sell and 20% buy, we would award a total of 6 nbt buy and 9 nbt sell out of our 15 nbt/month.
This should be controversial. Paying more to sell side when the network is in trouble? Am I nuts? Well, we are currently doing that to an extreme with fixed reward. This is a hybrid fixed reward/fixed cost model that I am proposing here.
What is the difference between fixed cost and fixed reward? Is it from the perspective of the network?
To me ALPPs provide liquidity with a fixed cost from the perspective of the network already.
Fixed cost fixes how much an operation costs shareholders. Fixed reward fixes how much an operation rewards participants. With fixed cost the operator specifies an nbt/day amount. With fixed reward the operator specifies rates and targets.
I have moved this server over to the BTC pool on Bter. It seems to be working well. It still kills itself every 24 hours because I don’t have Nud up. I also have not added the flex funds yet, I’m still considering the best approach for that.
@willy The way this would look for parametric order book (POB) is that instead of asking people to place orders at certain prices to get certain rates, the operator would state that it’s giving out a certain amount of NBT at a certain rate to anyone willing to put an order up at a certain price, letting all participants share the NBT proportionally to how much they participated. (I might not fully get POB though)
Noooope. That would be the ‘fixed reward’ system that already exists. Your reward will be based on how many other people are providing with you. The cost to shareholders is the thing that is fixed, which is not something you see directly as an LP. As an LP, you should expect higher reward when you are providing the bulk of the liquidity on a single side, despite the actual total liquidity that is being provided.
Think of fixed cost compensation like PoW mining BTC - there’s a constant (PoW: coinbase tx; here: compensation per time) reward for which all participants fight for. They get rewarded based on the resources they verifiably invest.
If the fixed cost model proves successful it might end up with different “pools” (1 ALP, 2 NuBots…) fighting for a compensation that Nu pays for liquidity on a particular exchange.
The comparison with BTC’s mining is very useful.
In fact, FC ALP’s compensation scheme could be the exact equivalent of it in the world of Nu’s liquidity provision competition.
There are 2 improvements that we should seriously consider. Both of these ‘improvements’ are actually a way of blending fixed cost with fixed reward:
Tiered costs. If a side has <100 NBT, pay x/day, if <1000 NBT pay y/day, otherwise pay the full amount z/day. This will decrease incentives to fix a broken peg, but they will also reduce shareholder costs when a peg is broken. We might also consider applying the tiers if either side has a broken peg, rather than just one side. That would make it a cooperative model.
Split pay. Pay (x+y)/day buy and (x+z)/day sell, where y+z=constant and y/z=ratio of sell:buy liquidity reported to the network for tier 1.
by ‘broken peg’ you mean a very thin wall, i assume.
i would porpose to make it a little more complex, to pay more for a tighter spread,
but the code could be hell
These steps make it very attractive to provide at least a little bit more funds than the threshold of taking the next step.
Providing 10 NBT liquidity is so much better than providing 99.
And providing 1000 NBT is waaaaay better than providing 999.
Nice!
This also motivates someone with a lot of sellside liquidity to make sure there is buy side liquidity. For example, someone has 10,000 sell NBT and there is only 999 buy NBT; they can double their daily rate just by making sure there is 1 more NBT of buy side. It doesn’t even have to be theirs and they would profit off of it. This gives them incentive to, say, post on the forum that the peg is broken.
simple f(x)=x is fixed reward if all participants are in cooperation. We would be forced to impose targets with dutch auction again to generate competition and we’d be right back where we started.
By applying tiers we can still make the statement that as long as at least 1,000 NBT is on both buy and sell walls the pool will pay a fixed total cost to participants of y NBT/day.
Not to my knowledge. The new ALP server software that is currently being worked on will use this model though.
I’ve been working on getting automated test coverage for the software, little way to go yet. The work on NuBot to integrate this into the web UI is taking place.
