I am aware that the question could have been answered many times but since liquidity is the blood of Nu, i think it is crucial to clarify the situation once again.
It comes down to ask the following 2 questions. In lay terms,
1- how does a fixed cost pool work?
2- how does a fixed reward pool work?
Which one is best and should become our standard?
Can someone give a numerical example that can help someone that knows nothing about nubits understand how she or he can make money with liquidity provision in each case 1- and 2-?
If Nu wants to become the currency of the Web, it s mandatory that liquidity is drastically increased, implying that Nu is able to attract many participants to the pools.
Wanna know the simple answer? The dutch auction method (what fixed reward is based on) is too complicated to code efficiently for more advanced operations. Check this out:
The concept is that there is at least the potential to be more than 1 provider. The less liquidity there is, the higher the reward % (as the total amount we reward per day is fixed). Therefore, the market should converge on the appropriate risk/reward ratio and provide us with a certain amount of liquidity. Theoretically, if we increase the fixed cost and the risk is linear (i.e. regular and not weird with thresholds and stuff) then it should linearly increase the liquidity provided. A pool with a broken peg represents an infinite reward/risk ratio and so theoretically draws liquidity from everywhere else in the network. @mhps is correct that without proper communication of a pool’s reward rates, this won’t necessarily work properly because LPs will be unaware of where the good LP deals are. Also, if the risk approaches infinity (i.e. high probability of exchange hack or an incorrect price feed) then a broken peg is more than possible. The NBT/CNY pool is an example of how an incorrect price feed can cause risks to approach infinity, as every bit of liquidity dropped into that pool was scooped up at a loss for the LP due to the blackmarket price of CNY.
Trying to reduce it to the marrow:
pay x NBT compensation per side.
Let liquidity providers compete to put orders within the spread.
Distribute the x across the provided liquidity.
Done.
With numbers:
pay 0.01 NBT per minute (14.4 NBT per day).
100 NBT within the spread are from LPs who run an ALP client.
Each single NBT (of the 100 NBT) earns 1/100th of the compensation.
The only reason I like the dutch auction is because unless the pool is “full” nu never pays out the maximum amount. This allows for roll-over which is money nu doesn’t have to spend next term.
Is there a way to incorporate that into the fixed cost model?
Sure, you could create fixed step costs and pay
x for liquidity below volume a,
y for liquidity between volume a and b and
z for liquidity above volume b
Obviously this works with more or less steps, but I’d rather have not too many steps, because by my gut feeling it will make the volume more stable the fewer steps you have.
It requires a sense for the relation between compensation and target volume.
The most simple approach would be only one step, e.g. pay half of the compensation for half the target volume and pay the full compensation above half the target volume.
I’m for infinite steps and having a max liquidity target.
Example (10 nbt/day total fixed cost between both buy and sell):
Every minute, take the 10 nbt/day at 5000 total liquidity, multiply by the actual total liquidity and divide by the 5000 (so 2000 total liquidity would get 4 nbt/day) then cut it in half and give it as fixed cost to either side. So if it’s 500 buy and 1500 sell the rates would be 0.4% buy and 0.133% sell.
Putting in more liquidity decreases your total payout for fixed cost, this is always true. With infinite steps, putting in liquidity proportionally on both sides while the pool is under target will actually keep the reward rate exactly the same, like a fixed reward pool. How would this cause oscillation?
Use the example above and double the LP on both sides. The reward is now 8 nbt/day and the rewards rates (%) all stay the same.
Infinite steps are rather a theoretical model than practically possible.
You will have a limited number of steps.
LPs that target a minimum compensation rate might create and cancel orders based on the current situation in between steps.
If future ALP clients have configuration parameters to adjust the liquidity volume to the current compensation rate, I fear this will lead to oscillation.
This is already an issue with fixed cost and is actually somewhat mitigated by the model I’m proposing here. This model helps this problem, it doesn’t make it worse.
If you say so, I tend to believe it
I should have spent more thoughts about it instead of creating uncertainty.
I will digest this topic a bit more before writing more nonsense.
Nah, thought and discussion is vital, you know that better than most.
Let’s focus on one side. There’s 10 nbt/day (fixed) and 750 nbt in the pool. You have your bot set to put up 500 nbt if the rate is >1% and take down 500 if the rate is <1%. As you can see, the bot begins oscillating.
Yes, of course there are ways to help with this. However, doing the combined-reward-fixed-cost (CRFC, I just made that up) model does not make this problem worse. This problem is generated because a change in liquidity provided causes a change in reward percentage. CRFC actually reduces this effect (the same change in LP would cause a smaller change in % reward because the fixed-cost amount changes some).
FR - Fixed Reward. Uses a constant % up to a target, then uses dutch auction.
FC - Fixed Cost. Uses a constant NBT/day with no target. % can be calculated from cost and liquidity provided.
CRFC - Combined Reward Fixed Cost. Uses a NBT/day proportional to the combined liquidity on both sides, maxing out at a target. If sides are held proportional (i.e. 50:50 or 75:25) this is identical to FR but using FC at the target instead of dutch auction.
Asymmetric Pool - varying the key constants separately for buy vrs sell side
Flex - varying the asymmetry of the pool based on the liquidity in the network.
I feel FR is suited to a situation in which you want a certain minimal return on your money against a certain risk. And I think this risk is the risk of exchange default.
Ex: You re willing to get at least x% a day in Polo from your funds but not less, otherwise you asses that it is not worth the risk of Polo.
I fee FR is well suite to centralized exchanges.
Conversely, I feel FC is suited to a situation in which you really do not care so much about a certain minimal return (you are willing to see how it goes and see in practice how many participants are competing for the reward) but you know that you will get some. Of course you can walk away if your bot detects that you do not get a certain minimuml but I interpret that in FC you do not specify a rate, do you?
In any case, I feel FC is well suited to a decentralized exchange in which the default risk is in practice 0.
In other words, I think a pool running at a decentralized exchange will offer much less rewards and providers will be fine with that and as long as they get something out of their money, they will be willing to leave it in the pool, and FC deals well with that since it will give your some rewards regardless of the competition.
For FR you say that they only participate if the pool is under target. If you assume a similar concept on FC pools, that the person walks away if the pool isn’t below a target, you can get similar results. For example, if there is less than 5000 nbt on a side in either NuPond pool, you know the rate will be >0.2%. So you can walk away if the liquidity exceeds this in a similar manner. That the FC pool causes more movement amongst custodians can be considered a boon, as it benefits pro-peg gaming of the pools to try to balance inter-exchange as best you can.
I’d like to see CRFC implemented. Sam’s stuff allows for all possible dynamics near as I can tell.
