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)
Just to clarify things, in a fixed total payout scheme, as a liquidity provider participant, I will have a guaranteed fixed reward per day.
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.
Got it now.
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
Broken peg could be thin wall or no wall. The argument is that if there is no buy side liquidity we should not be paying sell side as much.
Spread dependence would have to come after parametric orderbook.
@zoro You seem interested, what are your thoughts on this:
If LP on one or both sides is < 100 NBT, payout 1/10 rates.
If LP is <1,000 NBT on either or both sides, payout 1/2 rates.
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.
i was thinking of an analogous payment proportional to the wall size, following the simple function f(x)=x
but threshold may work good as well.
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.
Is there any other fixed cost pool besides nupond nbt/btc?
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.
With buyside reduced to 0 for 1.5% spread, why don’'t we deploy fixed cost (FC) scheme on the buy side?
Suppose the existing spread is 5.5% (0.75 on the sell and 4.75 on the buy) and our target is 1.5% (0.75% on both sides).
If we offer 100 NBt per day FC reward on the buy side, then how much liquidity we will attract to make it even? This :
Every time $N on the buy side BTC get bought, the LP will buy it back from the 4.75% buy wall and put it back at 0.75% buy side in order to get reward, incurring 4% loss. 100NBT will sustain 100/4% = 2500 NBT trade volume a day. Whoever makes the balancing will get to split the reward so I expect competition will bring more volume. (In a deleted version of this post I try to assume how many balances could happen a day. I think it is too unreliable.)
Is this worth to try? I think so because We are paying 140NBT a day for 0 buy side at 1.5% spread!
@woolly_sammoth @Cybnate @Nagalim and other pool runners please let me know if I explaned it clearly.
That is what we need now!
FC with an increased offset for starters is a good way to revive the liquidity provision.
It’s following that road - the 3% need to be replaced, though: